Mon, 27 Sep 2004

Apple does weird things with NTP

I’ve whined about the MacOSX weirdness with NTP previously, but today I spotted a new piece of utter stupidity from their setup. To recap, the original thing that got up my nose was the fact that, although you can indeed enter the name of your local NTP server in the dialogue box to override one of the far distant Apple servers, the UI doesn’t tell you that you have to reboot before it will take effect. Of course, you don’t have to reboot, but unless you know how to go and find and kill and restart the ntpd that’s running, the change won’t happen until you reboot. The bad thing is that, although they must know all this, they don’t tell you.

Anyway, I now have it using the local NTP server, known by the name “ntp”. Today, I noticed that they haven’t done anything to cope with the fact that ntpd, as delivered, doesn’t cope well with an environment where it spends days in close contact with a server and then spends some time alone—as happens with laptops. Yesterday, I noticed that the clock was about 15 seconds out, as a result of the hours I spent at Humbug on Saturday. This morning, it had drifted to 27 seconds and it was clear that I’d have to fix it manually. This rather defeats the otherwise simple business of moving from one network to another, but I’ll pass over that for now.

So I use ps and kill to stop the ntpd process. Then I run “ntpdate ntp” to set the clock. Short pause, then “Segmentation fault”. Nice work, Apple. On all the FreeBSD boxes on this network, that exact incantation works. OK, maybe we can try “ntpdate 172.16.11.99”. Great, that at least works and I can restart the daemon. But what earthly excuse is there to segfault without explanation on a perfectly sane invocation of an old program?

Posted at: 09:52

Path: /software/discuss   |  permalink