[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 127.0.0.1 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 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?
>
> 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?
Danny
>
> 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