If you are the one designing your applications, don't rely on SIGTERM and clean shutdowns. Design them so SIGKILL is the default way to stop them such that no data is corrupted and persistent state stays consistent. Then you don't have to rely on some rarely executed "recovery" code, or even worse take chances of what might happen if SIGTERM doesn't work.<p>Handle SIGTERM only if you get a blackbox-like application (a database that will break if you pull the power plug on it) and so on.
I know it's normally a good idea to avoid code duplication, but in this case I would have copied the function inside kms_functions into both kmsn and kmsp, since this removes the dependency on readlink and also makes it possible to move the executables around without care.
Alternative modes of operation that would be useful:<p>* Send SIGUSR1 if TERM doesn't work<p>* Send SIGCONT if TERM doesn't work<p>* Attempt to reap the process<p>* Attempt to ptrace the process<p>* Give a hint as to why it can't be killed (like blocked I/O, a zombie, etc)<p>* Kill the process group (dangerous!)
Often I need to kill processes, and wait until they're dead. I want to send a SIGTERM first, then a SIGKILL if it fails. And I want this process to be automated. That's it.
I really want to like this. But SIGKILL is such a special instrument in the administrator's toolbox that I don't want it automatically sent after a short timeout. Moreover I don't think anyone should want that. This tool will hide or allow you to ignore important issues with your system.<p>I do unequivocally like the blocking behaviour though, I might implement that for myself.<p>Edit: so just something like this:<p><pre><code> function killwait() {
kill $1
while ps -p $1 &>/dev/null; do
sleep 1
done
}</code></pre>
So instead of two kill messages, we now have two scripts to run, dependent on name or pid?<p>Just put everything in one script - these scripts are shorter than an init boilerplate section - and use an option to switch. Do process names by default, then perhaps use a -p arg to switch the script into 'pid' mode. Bash's 'getopts' is pretty easy to implement.<p>As it stands, you currently have to waste mental power to figure out whether you want the 'n' or 'p' version anyway, so may as well just make it an arg.
In my opinion, current process handling is braindead, both in POSIX and Windows. That could be "fixed" with an additional unique identifier during the OS uptime, in order to allow other processes track instances, and not just the ones doing the fork.
> Those should be available on almost any Linux system, even on minimal installs:<p>> [..]<p>> Bash<p>Maybe I'm nitpicking here, but why Bash _should_ be available?