SIGHUP signal

Perry Hutchison perryh at pluto.rain.com
Sat Feb 15 17:47:50 MST 2014


Paul Slootman <paul+rsync at wurtel.net> wrote:

> On Sat 15 Feb 2014, Perry Hutchison wrote:
> > Hiroyuki Ikegami <ikegam at mixallow.net> wrote:
> > > 2014-02-15 7:39 GMT+09:00 Grozdan <neutrino8 at gmail.com>:
> > > > Yesterday, I changed my rsyncd.conf file to add one more module to it.
> > > > Then I sent a kill -HUP $pid signal to rsync running in daemon mode,
> > > > but what gives? It just died so I had to start it up again. I though
> > > > sending a HUP would just make it reload its config file, no?
> > >
> > > Many softwares catches SIGHUP as a trigger to reload configurations.
> > > But it is a kind of software design. If the programmer does not want
> > > to write signal handling code, the programs received HUP just dies.
> > 
> > This really ought to go on the to-do list.  It is a very
> > longstanding convention that a daemon should reinitialize itself
> > (for some reasonable definition of reinitialize) upon receiving
> > a SIGHUP.
>
> Why should the code be modified to help those that don't read
> the docs properly?
>
> From the rsyncd.conf manpage:
>
>   Note that you should not send the rsync daemon a HUP signal to force it
>   to reread the rsyncd.conf file. The file is re-read on each client con-
>   nection.

Because "kill -HUP" after editing a config file is a standard
administrative workflow.  Google "Principle Of Least Astonishment".

Since rsyncd already reinitializes itself on each connection, all
that's needed is for it to ignore SIGHUP:

    #include <signal.h>
    ...
    signal(SIGHUP, SIG_IGN);


More information about the rsync mailing list