Support "superkill" with kill shell builtin

[AnthonyGiorgio]

I was debugging a problem with a filesystem where df was hanging. When I tried to kill the process, I discovered that kill -9 wasn't sufficient to terminate the process. I had to resort to superkill (kill -K) to terminate it. The problem that I encountered is that bash treats kill as a shell builtin, and it refuses the -K argument as an invalid signal. I had to call /bin/kill -K to actually issue the signal.
Would it be possible to add a patch to bash so that the shell builtin is able to handle this signal? There is a __superkill() API that could be used in this case.

[IgorTodorovskiIBM]

__superkill requires that a SIGKILL be sent to the process at least 3 seconds prior. If it has not been sent, it will issue an error:

A regular SIGKILL must be sent, at least 3 seconds, to a process before a superkill. Otherwise the attempt will result in EINVAL/JRSigkillNotSent.

$ /bin/sh
[\u@\h \w]$ sleep 10000 &
[1]     16777404
[\u@\h \w]$ kill -K 16777404
kill: FSUMF344 16777404: Cannot superkill without prior KILL signal to process
[\u@\h \w]$

I'm not a big fan of this behaviour personally. I'd rather it attempt to send a SIGKILL, check if the process still exists for 3 seconds, and then send a __superkill if it still exists.

[IgorTodorovskiIBM]

Another option is to keep -K the same (useful if you tried sending the sigkill manually), but introduce a -K2 (which attempts a sigkill and then a superkill as described above). Or I could improve the logic by attempting a superkill first, and if it fails due to EINVAL/JRSigkillNotSent, then perform the kill/superkill combo.

[AnthonyGiorgio]

After some internal discussion, I've come to the conclusion that we should mirror the existing behavior of /bin/kill and require the SIGKILL to be sent within three seconds of the __superkill().