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. 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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
