Help diagnosing why my program isn't trapping SIGTERM on shutdown

H

Henry Law

I have a program which runs in the background, doing its thing. When it
receives a SIGTERM it will tidy up and then exit. In test - running it
from a TTY, either in foreground or background, it behaves as expected.
But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
code that traps SIGTERM isn't executed, despite the Linxu manual
specifically saying that SIGTERM is passed to running processes. Can
someone who has encountered the problem help me to diagnose it? (I am
aware that it might turn out to be a Linux problem, in which case I'll
take it somewhere else ...!)

Here's the core of the code, called clpm.pl

#! /usr/bin/perl
use strict;
use warnings;
use Sys::Syslog;
use sigtrap 'handler' => \&terminate, 'normal-signals';
my $loop_count = 0;
my $timer = 0;
my $sleep_size = 10;
my $loop_size = 6;
openlog 'clpm.pl', 'cons,pid', 'user';
syslog 'info', 'starting up';
while (1) {
while (++$loop_count < $loop_size) {
sleep $sleep_size;
}
$timer += $loop_count*$sleep_size;
$loop_count = 0;
syslog 'info', "Running for $timer seconds";
}
syslog 'info', 'How did we get here?';

sub terminate {
syslog 'info', 'Normal signal received';
exit 0;
}

Here's the appropriate bit of the system log when I send signals manually:

Here's where CRON starts the task
Sep 1 16:43:01 neptune crond(pam_unix)[2263]: session opened for user
nfb by (uid=0)
Sep 1 16:43:02 neptune clpm.pl[2264]: starting up
Then I do "kill -TERM 2264" from a TTY and ...
Sep 1 16:43:29 neptune clpm.pl[2264]: Normal signal received
Sep 1 16:43:29 neptune crond(pam_unix)[2263]: session closed for user nfb
... that's where it handles the signal and stops.

But here's the system log when I reboot the machine with the "shutdown"
command:

Sep 1 16:45:02 neptune crond(pam_unix)[2283]: session opened for user
nfb by (uid=0)
Sep 1 16:45:02 neptune clpm.pl[2284]: starting up
... lines deleted
Sep 1 16:45:52 neptune clpm.pl[2284]: Running for 60 seconds
It was definitely running ...
Sep 1 16:46:15 neptune shutdown: shutting down for system reboot
Sep 1 16:46:15 neptune init: Switching to runlevel: 6
Sep 1 16:46:17 neptune xfs[1575]: terminating
Sep 1 16:46:19 neptune nmbd[1595]: [2006/09/01 16:46:19, 0]
nmbd/nmbd.c:terminate(56)
Sep 1 16:46:19 neptune nmbd[1595]: Got SIGTERM: going down...
... etc until the reboot happens. clpm.pl just vanishes!

Perl version is 5.8.6 running on Intel.
 
P

Paul Lalli

Henry said:
I have a program which runs in the background, doing its thing. When it
receives a SIGTERM it will tidy up and then exit. In test - running it
from a TTY, either in foreground or background, it behaves as expected.
But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
code that traps SIGTERM isn't executed, despite the Linxu manual
specifically saying that SIGTERM is passed to running processes. Can
someone who has encountered the problem help me to diagnose it? (I am
aware that it might turn out to be a Linux problem, in which case I'll
take it somewhere else ...!)

er. I may be missing something, but it sounds like you've *already*
determined it's a Linux problem, not a Perl problem. But to check,
write a program in another language, say C for example. Trap SIGTERM
there. Call it in *exactly* the same manner that you call your current
Perl program. Does its signal handling code receive a SIGTERM on Linux
shutdown?

Paul Lalli
 
X

xhoster

Henry Law said:
I have a program which runs in the background, doing its thing. When it
receives a SIGTERM it will tidy up and then exit. In test - running it
from a TTY, either in foreground or background, it behaves as expected.
But when I restart Linux (Fedora Core 4, using 'shutdown -r now') the
code that traps SIGTERM isn't executed, despite the Linxu manual
specifically saying that SIGTERM is passed to running processes. Can
someone who has encountered the problem help me to diagnose it? (I am
aware that it might turn out to be a Linux problem, in which case I'll
take it somewhere else ...!)

What happens if you send warnings into your own file, rather than using
syslogd?


Xho
 
H

Henry Law

What happens if you send warnings into your own file, rather than using
syslogd?

What a good question. I'll experiment. Mean time I threw myself on the
mercies of a C group and an obliging chap there gave me a skeleton of a
C program that does the same thing. As Paul suggested, knowing how it
behaves is key.
 
H

Henry Law

What happens if you send warnings into your own file, rather than using
syslogd?

For the record, I swapped my "syslog" code for some other code I have
which writes to its own log, after Xho's suggestion, and all works as
required. Thanks - I should have thought of that, since I don't use
syslog at all frequently and am not familiar with it.
 
P

Peter J. Holzer

For the record, I swapped my "syslog" code for some other code I have
which writes to its own log, after Xho's suggestion, and all works as
required.

And if you compare the timestamp of your file with the time that syslogd
was shut down you will probably guess what happened.

hp
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top