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

Rob nomail at example.com
Fri Apr 11 15:54:23 UTC 2014


Harlan Stenn <stenn at ntp.org> wrote:
> 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?

It cannot identify that.  But services are not supposed to get TTY HUP
signals and normal user programs (shells, editors) are not supposed to
use SIGHUP to re-read configuration files.

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

What you write is correct in itself.  If you really want to use SIGHUP
for two things, I suppose it would be possible to get the serial line
state in the signal handler and check the DCD state, and when it has
become false it could be assumed that the SIGHUP was caused by that.
(at least when DCD was true before)

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

I think the re-exec is not a preferred way to do it anyway.
But some early Unix daemons did that.  That was coded before chroot
and dropping privileges after startup became commonplace.



More information about the questions mailing list