> If a program fails permanently and dramatically when it's kill-9'd There are several kinds of bad state that can be left over: (1) space leaks (disk, memo

> If a program fails permanently and dramatically when it's kill-9'd There are several kinds of bad state that can be left over: (1) space leaks (disk, memory (sysv shared memory)) (2) inconsistent data (data / config files) (3) locks/semaphores (used to protect (2) from happening in normal operation) (We're talking about those that are under the control of the program itself, not the control of another program or the kernel (the latter can and generally will be cleaned up automatically).) Programs can be written to clean those up when they are restarted, which is the reason for the saying that if some program does not do that, then it's not worth being left installed. But it takes a certain amount of work writing code to recover from an abandoned lock and the possibly inconsistent state that has been left over, so much so that even some wide-spread system libraries don't do it. Of course you're free to remove those system libraries from your system, but you may have to write a replacement. Also, in the case of such libraries, it may happen that you lock out other programs (that also happen to use the same libraries) than the one you SIGKILL'ed, and you may not be aware of the source for the issue. In particular I'm thinking of ALSA. If you SIGKILL a program while it uses [a "hw:" device in] ALSA, it leaves behind a semaphore that prevents other programs from accessing the same device indefinitely (it seems there's no recovery code in the ALSA libraries). This robbed me of quite some time to figure out; when I did, I wrote a utility to clean up the semaphores explicitely[1]. Every now and then it happens that I need to reach out for it. [1] https://github.com/pflanze/chj-bin/blob/master/alsafix https://github.com/pflanze/chj-bin/blob/master/alsafix