I've seen a lot of process managers that try to do this. It was my understanding that you should only use SIGTERM to kill a process. The process could take an unknown amount of time to clean up after itself; on a slow system, it could take minutes. I always thought the only solution was to be patient, and wait for the program to clean up and exit gracefully. If the process does not catch SIGTERMs, then this is a bug and should be reported to the software's maintainer.
I've seen popular tools like docker also trying to do this:
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop a running container (Send SIGTERM, and then SIGKILL after grace period)
Is this bad practice? One thing I'm also curious about is how the shutdown procedure works on a SystemV-style init system. I've had a look at some manpages and some other questions but can't find a definite answer. I'm guessing each init service (terminology?) sees the change in run-level and executes the proper "stop" function as defined in the init script. Does it do this one-by-one, making sure each service ends properly? What happens to processes not handled by init scripts? I've seen some questions vaguely mention a grace period being used before SIGKILLing them, but I was hoping someone could elaborate or at least point me in the right direction. :)
If someone could help me find out more about how this works with systemd too, I'd be happy to research and find out more. I've had a look at the manpages but can't find anything definitive here either.