3 ms·
Not bad, but one big criticism, never do a 'kill -9' first, that will stop the program from cleaning up after itself if killed using -9. Use one of these inste
by jmclnx 7mo ago
Not bad, but one big criticism, never do a 'kill -9' first, that will stop the program from cleaning up after itself if killed using -9.
Use one of these instead:
-TERM then wait, if not
-INT then wait, if not
-HUP then wait, if not
-ABRT
If you are sure all of these fail, then use -9 (-KILL). But assume the program has a major bug and try and find another program that will do the same task and use that instead.
- BenjiWiebe 7mo agoHow often does plain 'kill <pid>' not work, but some other signal other than SIGKILL works? Usually the process is either working correctly and terminates when asked, or else not working correctly and needs to be KILLed.
- consp 7mo agoLots of commandline tools will hold on to dear life except for the sigkill. I often have this with running background tasks which get one of their threads in an infinite loop or wait state.
- chasil 7mo agoIt is possible to install a handler for most signals, and that handler can be configured to ignore the signal. Signal 9 cannot be ignored.
- gottheUIblues 7mo agoI don't think of 9 as really being a signal to the process at all, more of an instruction to the OS kernel to terminate the process
- adrianmonk 7mo agoMaybe this logic should be built into the "kill" command (or some other standard command). Given that this is the right way, it shouldn't be more tedious than the wrong way! It could also monitor the target process and inform you immediately when it exits, saving you the trouble of using "ps" to confirm that the target is actually gone.
- eptcyka 7mo agoKill is not a command to kill processes, it is a misnomer. Kill is meant to send signals to processes.
- jolmg 7mo agoDifferent programs may take different amounts of time to cleanup and close. To know if a signal failed takes human judgment or heuristic. A program receiving a signal is even able to show a confirmation dialog for the user to save stuff, etc. before closing.
- adrianmonk 7mo agoThat's a valid point. Another example is SIGHUP, which will cause some programs to exit but other programs to reload their config file. In certain very specific cases, that could even cause harm. So really what "kill" would be doing is automating a common procedure, which is different than taking responsibility for doing it correctly. It would need to be configurable. I still think it would be a net benefit since right now incentives push people toward doing something the wrong way (even if they know better). But I can also see how it might give people a false sense of security or something along those lines.
- jolmg 7mo ago> automating a common procedure It's not common. If `kill` on its own (which does just SIGTERM) doesn't work, you're already in "something wrong is happening" territory, which is why: >>> Given that this is the right way, it shouldn't be more tedious than the wrong way! is also the wrong way to think about this. Trying a sequence of signals is not so much "the right way" as it is "the best way to handle a wrong situation". The right way is just `kill` on it's own. SIGTERM should always suffice. If it doesn't to the user's satisfaction for a nonjustifiable reason, then you can just `kill -9`, but this should be rare. Trying a sequence of SIGINT, SIGHUP, and SIGABRT is technically better than SIGKILL but not really important unless you also want to write a bug report about the program's signal handling or fix it yourself. About SIGINT and SIGHUP, if SIGTERM doesn't work, it's unlikely that SIGINT or SIGHUP would. Likely, it would only be through oversight and the execution of default handlers. `kill -9` is just like `rm -rf`. I wouldn't suggest that `rm` automatically run with `-r` or `-f` when `rm` on its own didn't work, and I wouldn't call automatically trying those flags "the right way".
- consp 7mo agoThis is article is likely LLM generated and it regurgitates as first go what the last resort should be. After seeing that command I stopped reading.
- eptcyka 7mo agoNever use `kill -9`, instead refer to the signal directly. 9 is not always the same signal on all platforms.
- chasil 7mo agoHUP is usually sent to daemons to instruct them to reinitialize and reread their configuration files. Is it still passed when a terminal is disconnected? I understand a dial-up modem was involved in the original intended use.
- trympet 7mo agoOn a modern OS, doesn’t the kernel (eventually) take care of the cleanup anyways?