Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@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.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
