Re: [launchd-dev] (RESOLVED) SMJobBless not copying entire __launchd_plist
On Fri, Jul 9, 2010 at 15:30, Damien Sorresso <dsorresso@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.
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?
Richard Brown
On Jul 11, 2010, at 4:46 PM, Richard Brown wrote:
On Fri, Jul 9, 2010 at 15:30, Damien Sorresso <dsorresso@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.
participants (2)
-
Damien Sorresso
-
Richard Brown