[ntp:questions] ntpdate

Danny Mayer mayer at ntp.org
Tue Jun 16 01:52:42 UTC 2009

Scott Haneda wrote:
> Hi Danny, thanks for your comments...
> Replies below...
> 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 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 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 don't know what OS X does, maybe Brad, our resident MAC expert, can
tell us.

>>> 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.
> 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 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.
> 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 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.
> The network is up, I know this much for certain.

Is it querying the DNS to lookup the names of the servers and is your
resolv.conf pointing to or ::1? If so you cannot start this
until named finishes loading as it will unable to lookup the names.

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

See above. Are you doing lookups locally and is named running at the time?


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

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