That's what they put on the ticket, so that's what I'm using, but you're probably right.

SIGABRT is also not a normal termination signal. Seems out of place here.

SIGABRT would have to come from the process itself; IDK when if ever the shell would do that.

And SIGKILL can't be handled, so that is indeed pointless.

POSIX says that "setting a trap for SIGKILL or SIGSTOP produces undefined results", but for signals it describes SIGKILL as "Kill (cannot be caught or ignored)".

I'm guessing this is some relic from 80s Unix systems where SIGKILL behaved different, or perhaps just an inconsistency/oversight.

I read that as undefined in terms of how the shell itself handles it, because the OS doesn't care.

I think it means that it is valid for OSes to return an error instead of doing nothing, if you attempt it.

In sufficiently old Unix (I remember doing this on 32V) there was a fun little hack you could do with SIGKILL. If you sent SIGKILL to a process and that process was being debugged it would not kill the process. It would just pause it and notify the debugger that the process had received a signal, and tell the debugger which signal.

The debugger could then allow the signal to go through to the process as is, or to replace it with another signal, or have it be ignored.

I made a program that looked like sh in ps, but actually was a simple debugger that just ran a specific other processes of mine. When that process hit a signal the debugger poked the signal number into a fixed location in the process' memory, then changed the signal to something innocuous like SIGALRM, and let that be delivered.

The process' SIGALRM handler would get the original signal number that the debugger had poked in, and print some obnoxious message like "Stupid sysadmin...your wimpy SIGxxx cannot hurt me!" where xxx was whatever signal someone had tried to send it.

I then told my fellow admins I had a stuck process that I could not kill, and asked them to kill it.

It took quite a while before someone got suspicious enough to suspect that the sh that was the "stuck" processes parent wasn't actually a normal shell and try killing it.

That is quite a story!

It's like the software equivalent of an Annoyatron! I love it!

You can't, though probably common for a parent to spin off a child and handle the SIGKILLed child via waitpid().