Do not use kill -9

Argument -9 (or KILL ) for the kill command should be used on POSIX-compatible systems only when absolutely necessary. Why? The KILL signal cannot be processed by the process. This means that after the process is completed using kill -9 , the child processes will remain in memory and become orphaned, the file system will be clogged with temporary files, the shared memory segments will be active, the sockets will hang, and the atexit function (3 ) will not be executed at all. As a result, there is a risk of encountering unexpected and difficult debugging problems.



Instead, use the default TERM signal, and KILL only if less problematic signals prove ineffective:



$ kill 6738

$ kill -INT 6738

$ kill -HUP 6738

$ kill -KILL 6738



Even if the KILL signal fails to complete the process, this means that the process is likely to freeze when an I / O operation or is in some other uncompleted state. It may be necessary to reboot or force the unmount of a network drive bug.



Using kill -KILL by default is permissible when working with a problematic application, for example, older versions of Netscape often ended only with the KILL signal. However, this is a rare exception to the rule: use KILL for these previously known applications and only for them.

')

Issues at the completion of processes

Sequential sending of different signals can cause the following problems: first, the process may take seconds, or even tens of seconds, for correct completion. One product that I had to use required more than 30 seconds to complete properly after receiving the TERM signal. Fortunately, this feature was discovered during testing, so a suitable script was written for this case. Secondly, sometimes there are situations when the old process is completed, while the new process has taken its ID in the gap between the TERM and KILL signals. Systems with increased “routine” processes and systems where the kernel assigns PIDs in random order, for example, OpenBSD, are particularly at risk. Checking the process name or its PPID does not always help, since the new process can be a fork of the same parent and have the same name, therefore, especially paranoid scripts can also check the process creation time or other metadata before sending the signal. Perhaps these situations are rare, but they should be considered if you have to deal with a critical process.

Process completion signals

Process completion signals can be indicated by name or sequence number: kill -1 and kill -HUP equivalent. However, using a signal name is safer, since specifying the -1 argument makes it easy to seal up, sending a signal to another process or even a group of processes. Also, always try to use the name in the scripts, as this will help you better understand what type of signal is sent to the person who will read your code.



The HUP signal “hangs up” the shell, so this is a good way to clear the shell that hung while waiting for input, or to close an SSH session.



More detailed information about process termination signals is provided in the kill (1) man pages , and the kill -l displays a list of signals supported by the operating system. kill (2) describes system calls in detail. For more information, refer to The Design and Implementation of the 4.4 BSD Operating System or UNIX Internals: The New Frontiers .