[ntp:questions] ntpdate

Todd Glassey CISM CIFI tglassey at earthlink.net
Mon Jun 15 15:59:35 UTC 2009


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.
>   
Which creates an audit issue and security profile which always needs to 
be watched. NTPD is not the answer for everyone Danny.
>   
>> 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.
>   
As noted before NTPd is not the answer for everyone.

Todd Glassey
>   
>> 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
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.339 / Virus Database: 270.12.69/2176 - Release Date: 06/14/09 17:54:00
>
>   




More information about the questions mailing list