Restarting a Server on Demand (Perl Cookbook, 2nd Edition)

## 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

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