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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
