Stefan Unterweger wrote: > 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?
What is your network setup? dmesg too. any special kernel config? /Alexander
