[ntp:questions] Handle ntp conf modification when ntp is already running

Harlan Stenn stenn at ntp.org
Thu Apr 10 20:20:59 UTC 2014

Rob writes:
> Harlan Stenn <stenn at ntp.org> wrote:
> > Amongst the many reasons why we did not let SIGHUP restart the daemon
> > was that back in the old days we used modem drivers a lot more often.
> > The HUP signal was generic - it was not really associated with any
> > specific device.
> I think you are confusing two things.
> A modemline attached to a process does not send SIGHUP when the modem
> drops carrier unless the process has that modemline as a controlling TTY.
> So, when you have a daemon like ntpd that would open a modemline for
> some communication, it will not get the SIGHUP from there.
> SIGHUP as sent between processes to force a configuration reload is
> completely unrelated to SIGHUP as sent by tty lines when carrier drops.
> (and used to save files in editors, terminate an interactive session, etc)
> Sure it is confusing that the same signal is used.  Probably there should
> have been a separate SIGRECONF or similar.  However, in those days
> designers worried about using up a small number space, like signal
> numbers that are bitnumbers in a word, and thus limited to 1-31.

I'm still missing something then.

Unix signal handlers don't get any callback context.

So how can the handler know if it got a sighup because of a TTY HUP as
opposed to the signal arriving because the user wants to do a reload?

And I used to do a lot of signal stuff in general and SIGHUP processing
(both re ttys and for reload) but haven't done this in Years.  I may be

> Furthermore, the "simple solution" of having SIGHUP perform an exec
> of the same binary, thus in fact restarting the entire process and
> losing all state information, is not the only possible solution.

If the current process has chroot()ed, how do you re-exec?  How do you
handle the things that are done before the chroot()?  Again, I haven't
looked at the code to be sure, but I believe there are some things that
will behave differently if they are attempted from the chroot() target.

Sure, one could have a top-level master process that simply waits for
the chroot()ed subprocess to die and then restarts it, but we're
starting to get in to a lot of wheel-reinventing here, and would this
really be worth the overhead on a program that is already larger and
more complicated than many folks want?

> It is also possible to make SIGHUP parse the configfile into a new
> datastructure, then let the program determine the differences between
> the old and new situation, and perform the necessary changes (like adding
> and removing servers), without disturbing existing associations and the
> frequency control loop.
> This of course requires a lot more effort, especially when this was
> not designed in from the start.

Yes, and it is something we can slate in for at least consideration for
the next rewrite of the codebase.


More information about the questions mailing list