[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
misremembering.

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

H


More information about the questions mailing list