Re: Signals and END block

When the machine is rebooted or shut down, processes will receive SIGTERM first, having a chance to terminate cleanly, after five seconds the remaining processes will be forcibly terminated with a SIGKILL. You can check for yourself reading the /etc/init.d/halt script in a Red Hat Linux installation.

As you say, SIGKILL cannot be caught so it won't trigger the END block. However, it is bad practice to abruptly terminate a process with SIGKILL without trying SIGTERM first.

Finally, as long as the signals you're handling can be caught and make your script die, the END block should always be executed. Why not having the cleanup code in the signal handler itself, though?

As a side note, why don't you try to detect and delete the stale database record at startup if possible? This seems safer and it prevents loopholes as well, for example if the process is terminated with SIGKILL.

Comment on Re: Signals and END block Select or Download Code

Replies are listed 'Best First'.
Re^2: Signals and END block by Marcello (Hermit) on Aug 04, 2004 at 09:34 UTC
The `halt` script indeeds clarifies this question. First a TERM signal and after 5 seconds a KILL signal. Why not having the cleanup code in the signal handler itself, though? It also needs to execute when the programs ends normally, so the END block is probably the best place. Why don't you try to detect and delete the stale database record at startup if possible? Since I store the PID value of the process in a database, this PID might be re-used by the operating system when deleting the record at startup. Thanks for your helpful input.	[reply] [d/l]
Re^3: Signals and END block by bluto (Curate) on Aug 04, 2004 at 16:00 UTC
Since I store the PID value of the process in a database, this PID might be re-used by the operating system when deleting the record at startup. There is no way to handle 100% of the termination cases at the time of termination no matter what you do (e.g. your machine suddenly loses power and the UPS fails), so you must have code that detects stale records at some future point in time. There are several ways of doing this. The canonical way to verify a pid is to record it in a lock file that the process keeps locked while it is running. When you verify the pid, if you can lock the file, the process has obviously died. Another more generic way could be to write a separate "checkpoint" record that you remove in your END block. If you start up and the checkpoint record exists, you remove the stale PID record the that checkpoint record points to as well as the checkpoint record.	[reply]
Re^3: Signals and END block by etcshadow (Priest) on Aug 04, 2004 at 15:20 UTC
Since I store the PID value of the process in a database, this PID might be re-used by the operating system when deleting the record at startup. Right, but you can check to see if that pid exists, and if so, what process actually holds that pid. If the process that holds the pid is not the same as the process you are tracking, then you can assume that your process was killed abruptly and that you can delete the pid-record and start. `------------ :Wq Not an editor command: Wq` [download]	[reply] [d/l]


go ahead... be a heretic
	PerlMonks