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

[Damien Sorresso]

On Jun 1, 2009, at 12:47 PM, Scott Haneda wrote:
> On Jun 1, 2009, at 12:32 PM, Damien Sorresso wrote:
> On Jun 1, 2009, at 12:00 PM, Scott Haneda wrote:
>>> In a case where launchd works just fine all the time, for example:
>>>
>>>  [snip...]	
>>>   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.
>
> Nice, thanks.  What gets passed into StandardOutPath?  I assume  
> anything the script outputs via a plain echo, will be intercepted to  
> the log?  This is really nice, as I can then debug scripts as usual,  
> and not have to run a tail -f on some log somewhere.

Anything written to stdout. So echo qualifies as well as any command  
output you've piped into your own stdout.

>>> 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.
>
> Ok, understood.  The trouble is, ntpdate is failing then, and I have  
> no way to get the date set to 1969.  Any attempts to do so via GUI,  
> drop it back to current date.  I can shove it to some other date,  
> but ntpdate does not error when run.
>
> How can I mimic from an interactive shell exactly what launchd is  
> doing, so I know I am on the same page?  Any idea how to get the  
> system clock into 1969?  I really do not want to pull a pram battery  
> in this laptop :)

I'm not sure I understand what you're asking. If you want to see why  
ntpdate is returning an exit code of 1, you should read their  
documentation or their source. Also, logging the output of the  
invocation of ntpdate would probably be useful for you.
-- 
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/514b0973/attachment.bin>