Assuming that service does not leave things in "dangerous" or inconsistent state (though failures to carry tasks will be observed), should it close files, connections and any other work?
Should a service cancel and terminate incomplete work on SIGTERM
signals
Related Solutions
If you send a signal to a process, that process gets killed. I wonder how the rumor that killing a process also kills other processes got started, it seems particularly counter-intuitive.
There are, however, ways to kill more than one process. But you won't be sending a signal to one process. You can kill a whole process group by sending a signal to -1234 where 1234 is the PGID (process group ID), which is the PID of the process group leader. When you run a pipeline, the whole pipeline starts out as a process group (the applications may change this by calling setpgid or setpgrp).
When you start processes in the background (foo &), they are in their own process group. Process groups are used to manage access to the terminal; normally only the foreground process group has access to the terminal. The background jobs remain in the same session, but there's no facility to kill a whole session or even to enumerate the process groups or processes in a session, so that doesn't help much.
When you close a terminal, the kernel sends the signal SIGHUP to all processes that have it as their controlling terminal. These processes form a session, but not all sessions have a controlling terminal. For your project, one possibility is therefore to start all the processes in their own terminal, created by script, screen, etc. Kill the terminal emulator process to kill the contained processes (assuming they haven't seceded with setsid).
You can provide more isolation by running the processes as their own user, who doesn't do anything else. Then it's easy to kill all the processes: run kill (the system call or the utility) as that user and use -1 as the PID argument to kill, meaning “all of that user's processes”.
You can provide even more isolation, but with considerably more setup by running the contained processes in an actual container.
There are a number of signals whose default disposition is to terminate the process. The ultimate termination signal is SIGKILL since it cannot be handled and the process has no choice but to die. This however also means that if you send it, the process is deprived of an opportunity to clean up. Therefore, good manners require to send a signal like SIGTERM that can be handled first and only if the process does not exit after some time send it SIGKILL.
Note that SIGINT and SIGQUIT are not good candidates for arbitrary process termination. Due to the fact that they can be generated from terminal's keyboard, many applications use them for special purposes. For example, python interpreter uses SIGINT to generate KeyboardInterrupt exception (also in interactive python sessions where it simply returns to the prompt) and JVM uses SIGQUIT to dump stack traces. SIGINT and SIGQUIT do remain effective for most standard command-line utilities like find or cat.
During system shutdown, most UNIX and Linux systems send SIGTERM to all process, followed by 5 seconds wait, followed by SIGKILL. This is the recommended way to safely shut down an arbitrary process.
Note also that even SIGKILL may not terminate a process stuck in an uninterruptible wait until the process wakes up.
Best Answer
Yes it should. If it does or not is up to the utility.
Files and connections are usually closed when a program exits for whatever reason, however "other work" may be left half-done (temporary files may be left behind, databases may possibly be in a questionable state, data actually not written to files will be lost etc.)
A program may catch the
TERMsignal in a signal handler and exit gracefully, i.e. finish off anything it was doing and leave the world in an orderly state upon actual termination. It may also catch and ignore the signal completely.