Hello! I have noticed a rather curious behaviour of ntpd on startup. I recently started setting the '-s' option to ntpd in rc.conf.local on my machines. The sloppy hardware clocks on those machines combined with the lack of any kind of USV often leads to several minutes of clock skey on reboot (they are supposed to run 24/7, so unless I do an upgrade every reboot is "unclean"). Some services depend on accurate time synchronization, so they won't come up again after reboot.
Thus the '-s'. As far as I understood from the manpage, it's supposed to set the clock immediately on invocation and store it back into the hardware clock, and according to my tests it just does that. Unless it is supposed to to that on boot, read: when invoked from rc(8). Watching the console, I see that ntpd fails to stay up and throws up on my feet (without having set the clock, of course). /var/log/daemon has the following to say: | Jun 17 07:38:26 knoedel ntpd[17639]: ntp engine ready | Jun 17 07:38:26 knoedel ntpd[17639]: fatal: recvfrom: Protocol not available | Jun 17 07:38:26 knoedel ntpd[27003]: dispatch_imsg in main: pipe closed (I did set a bogus time into the hardware clock on purpose to see if this would work.) If I issue 'ntpd -s' after boot has completed, everything runs fine; same thing if I run ntpd from rc.local, but somehow this feels unclean. intro(2) says the following about the error message: "42 ENOPROTOOPT Protocol not available. A bad option or level was specified in a getsockopt(2) or setsockopt(2) call." But I am not enough of a programmer to make sense of this description. Is this some kind of bug, or am I simply trying to do something that is not supposed to be done this way? Thanks for any advice, s//un
