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

Rob nomail at example.com
Thu Apr 10 16:51:40 UTC 2014

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.

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.

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.

More information about the questions mailing list