
![]() | ![]() |
17.18. Restarting a Server on Demand
17.18.1. Problem
You want your server to shut down and
restart when it receives a HUP signal, just like
inetd or httpd.
17.18.2. Solution
Catch the SIGHUP. Within the handler, set harmless signal handlers,
unblock signals, and re-execute your
program:use POSIX qw(:signal_h sigprocmask);
my $SELF = "/path/to/my/program";
my @ARGS = @ARGV; # save for later
$SIG{HUP} = \&phoenix;
# your program
sub phoenix {
# make signals harmless
for my $nal (qw[ALRM CHLD HUP INT PIPE TERM]) {
$SIG{$nal} = sub { };
}
# reenable them
my $s = POSIX::SigSet->new;
my $t = POSIX::SigSet->new;
sigprocmask(SIG_BLOCK, $s, $t);
# and restart
print "Restarting\n";
exec $SELF => @ARGS;
die "Couldn't exec $SELF => @ARGS\n";
}
17.18.3. Discussion
It sounds simple ("when I get a HUP signal, restart"), but it's
tricky. You must know your own program name, and that isn't easy to
find out. You could use $0 or the FindBin module.
For normal programs, this is fine, but critical system utilities must
be more cautious, as there's no guarantee that $0
is valid. You can hardcode the filename and arguments into your
program, as we do here. That's not necessarily the most convenient
solution, however, so you might want to read the program and
arguments from an external file (using the filesystem's protections
to ensure it hasn't been tampered with).Be sure to install your signal handler after you
define $SELF and @ARGS;
otherwise there's a race condition when a SIGHUP could run
restart but you don't know the program to run.
This would cause your program to die.Signals are tricky beasts. When you exec to
restart your program, the reborn version inherits a set of blocked
signals from its parent. Inside a signal handler, that signal is
blocked. So if your signal handler simply called
exec right away, the new process would have SIGHUP
blocked. You could only restart your program once!But it's not as simple as unblocking SIGHUP using the POSIX module's
sigaction. Your program might have blocked other
signals (ALRM, CHLD, and the others listed in the
phoenix subroutine in the Solution), and those
would also be blocked. If you simply unblocked them, your SIGHUP
handler might be interrupted by delivery of those signals, so you
must first give those signals a harmless handler. That's the purpose
of the foreach loop in phoenix.Some servers don't want to restart on receiving a SIGHUP—they
just want to reread their configuration file.$CONFIG_FILE = "/usr/local/etc/myprog/server_conf.pl";
$SIG{HUP} = \&read_config;
sub read_config {
do $CONFIG_FILE;
}
Some observant servers even autoload their configuration files when
they notice that those files have been updated. That way you don't
have to go out of your way to signal them.
17.18.4. See Also
The exec function in Chapter 29 of
Programming Perl and in
perlfunc(1); Recipe 8.16; Recipe 8.17; Recipe 16.15
![]() | ![]() | ![]() |
17.17. Making a Daemon Server | ![]() | 17.19. Managing Multiple Streams of Input |

Copyright © 2003 O'Reilly & Associates. All rights reserved.