scott at newgeo.com
Mon Jun 15 20:27:05 UTC 2009
Hi Danny, thanks for your comments...
On Jun 14, 2009, at 9:00 PM, Danny Mayer wrote:
> Scott Haneda wrote:
>> I am only looking for the basics of keeping my system clock in sync
>> OS X 10.5. On OS X 10.5 the clock will drift badly on a machine
>> that is
>> not logged in. If you log in, it is less of a problem, but the
>> date and
>> time parts of OS X do not check into the time servers nearly often
>> enough. An idle machine is usually fine, but certain types of
>> applications can stall the OS, and in turn, stall the clock. For a
>> server, this makes log files a royal pain to deal with timestamps.
> You should be running ntpd as a daemon. That will keep the clock in
> synch and you never have to touch it.
I will look at this. It seems, OS X, in it's GUI based controls, has
a "use network time server", but it is known, and documented in
regards to OS 10.4, to not be reliable. I am not sure the position on
OS 10.5, which I am using, though I suspect there are still issues, as
when I have that setting on, I still get major drift of time.
>> I run, on a schedule, with launchd, which can be thought of as a cron
>> like scheduler for OS X, once an hour, and also, when the machine
>> boots. Launchd can be told to run on load as well. I sleep the
>> long enough for all interfaces to come up.
>> Here is my command:
>> /usr/sbin/ntpdate -u
> Why are you bothering to do this when you can just run ntpd as a
> which will keep your clock perfectly synchronized.
I was just not aware that there was an alternate way, in part, why I
was asking questions here.
>> This works fine, all the time, sans one exception. If the machine
>> has a
>> kernel panic, or some form of more serious crash, it will come up
>> the date and time set to 1969, which I believe is Apple's epoch (
>> December 31, 1969, at 4 pm PST )
>> This happens on all OS X machines, I have only tested on 10.4 and
>> and only on PPC hardware, I do not have a way to get the date and
>> to fall into 1969 on an Intel machine.
> I don't know OS X but I cannot imagine why it would do that.
It appears when there is a kernel panic, the machine loses NVRAM,
which is where the date and time settings are stored, backed up by a
on board battery. When that setting is lost, the date defaults to the
earliest date the OS supports.
>> When this happens, I can see in my syslog, that /usr/sbin/ntpdate -
>> u is
>> called, on the normal schedule, but the date and time is never
> You need to have a network connection first and I suspect you don't at
> that point, hence the problem. The network interfaces need to come up
> first, and then you can query for the correct time.
The network is up, I know this much for certain.
>> Syslog tells me, as a normal working result:
>> Jun 10 00:40:48 moses com.domain.ntpdate: 10 Jun 00:40:48
>> ntpdate: adjust time server 188.8.131.52 offset -0.070716 sec
>> * That is actually the output of launchd to syslog, lunachd just
>> the output of a command into syslog.
>> Here is a failure line, after I had a kernel panic.
>> Dec 31 16:00:54 host-domain-com com.apple.launchd >>
>> (com.domain.ntpdate): Exited with exit code: 1
> Where's the part of the log that shows when the network interfaces are
> up and running?
Unfortunately, my logs have been rolled out. This happens
infrequently. The next time it happens, I may be able to get a log
snippet. The trouble is, even that is hard to catch. OS X's syslog
will get stamps set to Dec 1969, the log rolling utility will see
that, and roll it away. I will look into how to disable the log
rolling for a time.
>> What is exit code 1 of ntpdate?
> I don't know and it doesn't matter. ntpdate is deprecated. you should
> used ntpd -gq instead if you just want to set the clock and ntpd -g if
> you want to discipline it so that it never is off.
I was not aware of this, thank you. I tried to use ntpd in the past,
since there is more data that I was able to find about it. It would
never adjust the time and date for me, so I abandoned it. Turns out,
even with debugging enabled to very high levels of verbosity, ntpd
will still return nothing when run.
I finally happened to be watching the syslog when I ran it, and there
it reports a message that I did not have privileges to be running it.
su'ing to higher level user allowed me to get it work.
ntpdate on the other hand, reports the privilege error to stdout,
which is why I ended up using it.
>> Interestingly, all I have to do to solve this, is ssh in, and run
>> /usr/sbin/ntpdate -u, at which point, the lunachd scheduler will
>> have no
>> issue with it on the next run. I can not find any way to do this
>> without user intervention. Being on a email server, I get a lot of
>> calls that their emails are dated wrong.
> Note that you cannot ssh in until you have a network interface
> If ntpdate is trying to run before they are working it will fail as it
> cannot make any network connections.
Then shouldn't I get an error message to that effect? Servers times
out or something of that nature? I actually see those errors when
time.apple.com goes down, but I do not see them in this case.
I am certain my network is up, or I would not be delivering emails
date stamped to 1969 from this machine. While that happens, I can
also see the exit 1 in the syslog, when the scheduler tries to run the
command. I have a medium load email server, when it is not working, I
hear about it from a client quickly. I know that is not as good as a
line in the logs, though BIND/named is also ran on this machine, many
things that require an interface to be up, are working.
Finally, I am looking at the exit 1 happening via ssh, the mere fact I
can do that, means that interface is up. If ntpdate is defaulting to
hitting up some other IP I have homed to that interface, there is a
chance that one is not up, though OS X enables them all at the same
>> I first confirmed with the launchd mailing list that this was not an
>> issue with launchd, and they felt certain it was not. This I am not
>> sure of, since if I can call the same command by hand, and lunachd is
>> doing the exact same thing, it makes it confusing as to where the
>> issue is.
>> Any more data, would help a lot, if it turns out to not be a ntpdate
>> issue, I need something to go back with to the launchd list.
> It has nothing to do with either launchd nor with ntpdate. It has to
> with your configuration setting trying to run ntpdate too early. If
> I am
> wrong please provide evidence.
I will work to get logs, though I believe mail delivery to be strong
evidence it is not a down interface. What would be better, is to
learn what exit 1 means, and perhaps to get it to log more data about
what it is failing on.
As I mentioned earlier, this happens rarely, in a kernel panic I can
not make happen, and rare enough, as well as on a machine I need to
have up as much as possible. My usual case is to simply fix it ASAP
so my phone can stop ringing with annoyed clients.
Thanks for the suggestions. To start, I will write a replacement for
ntpd on OS X that does not rely on the built in system commands to
run, which seem to be unreliable.
More information about the questions