Rob writes: > Harlan Stenn <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
