Restarting ntpd on address change

[Brooks Davis]

On Tue, Nov 29, 2005 at 09:01:16PM -0500, Ian D. Leroux wrote:
> Greetings,
> 
> My machine's ip address is assigned by DHCP, and whenever it changes
> ntpd stops functioning and must be restarted.  I gather this behavior
> will be changed in some future ntpd version, but in the meantime I had
> added a line to my /etc/dhclient-exit-hooks to restart ntpd every time a
> new address was obtained:
> 
> # [...] setup variables for ipcheck
> 
> if [ -n "$new_ip_address" ]; then
>   # [...] run ipcheck to update my dyndns
>   /etc/rc.d/ntpd restart
> fi
> 
> This seemed work fine on 5.4, but on 6.0 it gives problems at boot.
> Specifically, I get repeated "bad file descriptor" errors after my
> network address is assigned, and running ps after the boot completes
> shows that there are two ntpd processes running.  Killing one of them
> stops the file descriptor errors.  My interpretation of this (for what
> it's worth) is that an ntpd process gets started before dhclient gets a
> chance to configure the address (perhaps when the interface initially
> comes up) and then when the address is assigned the /etc/rc.d/ntpd
> restart starts a second process, but somehow fails to stop the first
> one.  For now I've removed that line from dhclient-exit-hooks, which
> avoids the problems at boot time.
> 
> I have the feeling that I'm not doing the Right Thing here.  So is there
> an accepted (or at least known-good) way of automatically managing the
> restart of ntpd on address change?  Have I found a bug in rc.d worth
> investigating? Or should I just stick to manual restarts until ntpd
> stops needing them?

Hmm, this should work because the pid file should prevent ntpd from
getting started twice.  That happens on my -CURRENT laptop so I'm
thinking there's something going on in the startup process that's
tripping you up.  One thought I had was that /var/run might be getting
cleared, but it doesn't look like that should be the case.

On a tangential note, the ntpd script won't actually support chroots due
to it's broken assumption that devices can exist outside devfs file
systems.

--- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051129/65412195/attachment.bin