On Jun 1, 2009, at 12:00 PM, Scott Haneda wrote:
In a case where launchd works just fine all the time, for example: <dict> <key>Label</key> <string>com.host.ntpdate</string> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>/Users/me/bin/set_date</string> </array> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>3600</integer> </dict>
script... (slightly shortened) #!/bin/bash # Create a place to store this log file log_path=/Users/me/Library/Logs/ntpdate.log
echo `date` >> $log_path
# Sleep for a duration so the system can get the interfaces up # Running in chunks just so the log and get updated # and I can see that it is working
echo "Sleeping...90 Seconds `date`" >> $log_path /bin/sleep 90;
# Do the work echo "About to run ntpdate -u" >> $log_path /usr/sbin/ntpdate -u echo "Finished running ntpdate -u" >> $log_path
log... (Full output, non shortened) ----- BEGIN ----- Started to set time and date Mon Jun 1 11:18:35 PDT 2009 Sleeping...30 Seconds Mon Jun 1 11:18:36 PDT 2009 Sleeping...30 Seconds Mon Jun 1 11:19:06 PDT 2009 Sleeping...15 Seconds Mon Jun 1 11:19:36 PDT 2009 About to run ntpdate -u Finished running ntpdate -u Finished setting time and date ----- END -----
You should use the StandardOutPath key (pointing to /Users/me/Library/ Logs/ntpdate.lo) in your launchd job, that way your script doesn't have to worry about echo(1)ing to a log file. Its stdout will just be redirected to the log file. This results in less complexity for your script.
Syslog tells me it works: Jun 1 10:57:41 host com.host.ntpdate[19696]: 1 Jun 10:57:41 ntpdate [19776]: adjust time server 17.151.16.21 offset -0.070842 sec
It works all the time, sans one case, which is when I need it most. I hope there are people here who know a but about the kernel of OS X. When the machine panics, which I am still working on determining why, I suspect ram, though on the 3rd batch. I have 100% ruled out a bad pram battery.
After a panic, the "automatically restart after power failure" feature does not work. It does work any other time, only after panics does not it. I have to physically reboot. This also adds more credence to the battery being fine.
When the machine comes up, there is a message on screen about the date and time being at 1969. Doing a google search for "panic 1969" and you see there are a good deal of others with panic logs at 1969. I conclude, panics mess with the date and time for some reason, or nuke nvram, not sure.
No big deal really, though this is an email server, and if I forget, or do not have access, the date and time will continue to be wrong, and all emails will be wrongly dated.
My plist is set to run at load, and also to run every 60 minutes, which I see it does do. I can find a syslog line that shows it ran at load, and ones that show it runs every hour as well.
launchd totally fails to run this item after a kernel panic and the date is set into the 1969 range. I have the sys log for where the dates are all Dec 31, which is just after the panic, and after I called in a reboot, which then foiled my script from setting the date correctly.
I see named started, which uses launchd, so I know it is working. I see a lot of other things start. But then I see this:
Dec 31 16:00:54 host-domain-com com.apple.launchd[1] (com.domain.ntpdate[50]): Exited with exit code: 1
You're drawing bad conclusions. launchd did, in fact, start the job. It has a PID and exit status and everything. The job just exited unsuccessfully. Not really launchd's fault. Don't interpret "The job failed" as "launchd did not start the job". All we do is start the job and get out of the way.
Right after that, I have a launchd item that checks S.M.A.R.T. which runs. Since this is after bind came up, I am pretty sure the interfaces are up enough that I could talk to a time server.
Is there something about ntpdate that will error out on insanely large time offsets? All I end up doing to solve it is `sudo /usr/ sbin/ntpdate -u`, the same thing launchd should do.
I will solve the panics, in the meantime, I would love to know how to protect myself from living in the past for too long. Thank you all.
Are you sure you even need to do this? Mac OS X should adjust clock drift automatically. -- Damien Sorresso BSD Engineering Apple Inc.