[ntp:questions] ntpdate

Danny Mayer mayer at ntp.org
Mon Jun 15 04:00:18 UTC 2009


Scott Haneda wrote:
> I am only looking for the basics of keeping my system clock in sync on
> 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 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 script
> 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 daemon
which will keep your clock perfectly synchronized.

> 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 with
> 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 10.5,
> and only on PPC hardware, I do not have a way to get the date and time
> to fall into 1969 on an Intel machine.
> 

I don't know OS X but I cannot imagine why it would do that.

> 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 synced. 

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.

> At first I thought I needed to tell it I will allow ntpdate to jump huge
> ranges of times, but I do not believe that to be the case.
> 

ntpdate doesn't care, it just sets the clock.

> Syslog tells me, as a normal working result:
> Jun 10 00:40:48 moses com.domain.ntpdate[78719]: 10 Jun 00:40:48
> ntpdate[78741]: adjust time server 17.151.16.21 offset -0.070716 sec
> 
> * That is actually the output of launchd to syslog, lunachd just passes
> 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[1] >>
> (com.domain.ntpdate[50]): Exited with exit code: 1
> 

Where's the part of the log that shows when the network interfaces are
up and running?

> 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.

> 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 working.
If ntpdate is trying to run before they are working it will fail as it
cannot make any network connections.

> 
> 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
> 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.
> 
> Thank you

It has nothing to do with either launchd nor with ntpdate. It has to do
with your configuration setting trying to run ntpdate too early. If I am
wrong please provide evidence.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the questions mailing list