You can't trap kill can you? doesn't that just go kill your process without any possibility of intervention or other actions? Also you probably want to handle HUP there too I would think (depending on what the script does)
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 parent of the "stuck" process wasn't actually a normal shell and try killing it.
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.
