[launchd-dev] Is there anything that can prevent launchd from working

[Damien Sorresso]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2425 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/launchd-dev/attachments/20090601/8f874059/attachment.bin>