[launchd-dev] (RESOLVED) SMJobBless not copying entire __launchd_plist

[Damien Sorresso]

On Jul 11, 2010, at 4:46 PM, Richard Brown wrote:
> On Fri, Jul 9, 2010 at 15:30, Damien Sorresso <dsorresso at apple.com> wrote:
>> On Jul 9, 2010, at 6:33 AM, Richard Brown wrote:
>>> The documentation for SMJobBless states that "[t]he helper tool must
>>> have an embedded launchd plist. The only required key in this plist is
>>> the Label key."  This implies to us that other keys in the embedded
>>> launchd plist (except Program and ProgramArguments) will be respected.
>>> 
>>> However, we find that the executable is copied into place, but only
>>> the Label of our embedded launchd plist (and the ProgramArguments
>>> generated by the API call) is written out to the
>>> /Library/LaunchDaemons/reverse-dns-label.helper.plist.
>> 
>> We'll also remove the Program key. Otherwise, I'd have to see your plist to diagnose further.
> <snip>
>> It sounds like your plist is somehow getting truncated.
> 
> Using otool and a hex2bin tool, we confirmed that the plist was indeed
> being truncated during the -sectcreate.
> It seems that our plist file had some manner of deficiency (unexpected
> line-break type, perhaps?).  It is strange, though, that we could open
> and read the file (initially generated with a shell script) in the
> Property List Editor with no difficulty; yet saving it with no
> modifications from that utility fixed whatever problem caused the
> truncation.
> The API is working for us now.

Wow, that's weird. If you can reproduce the issue, you should file a bug against Property List Editor.

>>> Can anyone help explain these issues?  Should we try a workaround of
>>> SMJobCopyDictionary / mutate dictionary / SMJobSubmit to get our other
>>> keys/values into the launchd plist?
>> 
>> 
>> That won't help. Those APIs don't touch the plist on-disk.
> It's not clear to me what "SMJobSubmit submits the given job to the
> specified domain" means if it doesn't touch the plist on-disk; is it
> only for one-shot jobs?


It just takes a CFDictionary. If that CFDictionary was created from some plist on-disk, then (provided it is in one of the standard locations enumerated in launchd(8)) it will be automatically loaded. 
-- 
Damien Sorresso
BSD Engineering
Apple Inc.