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