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