[launchd-dev] Can a launchd job get any access to its invoking plist?

[Damien Sorresso]

On 4 Dec, 2013, at 12:58, Norman Gray <norman at astro.gla.ac.uk> wrote:
> Damien (and Jerry), hello.
> 
> On 2013 Dec 4, at 20:10, Damien Sorresso <dsorresso at apple.com> wrote:
> 
>> On 4 Dec, 2013, at 12:05, Jerry Krinock <jerry at ieee.org> wrote:
>>> On 2013 Dec 04, at 11:22, Damien Sorresso <dsorresso at apple.com> wrote:
>>> 
>>>> Why not just set a relevant environment variable or pass an argument that's different in each plist?
>>> 
>>> I’ve done that, Damien, but like Norman I have wondered why the job’s parameters are not more readily available.  
>> 
>> Because the launchd.plist is not a preferences container. It's not meant to be a state store.
> 
> Sure, and I'm storing the actual state in preferences, using NSUserDefaults.  All I really want to know is "Have I been invoked from A.plist or B.plist?"
> 
> I've tried setting an environment variable, and passing an --ident option to the program.  That does work, but in each case it involves copying the Label from one part of the plist to another: that looks ugly, is redundant, and requires extra documentation ("Copy the Label to the --ident option; don't ask why...").
> 
> I've even resorted to concatenating various arguments and options, and using that as the 'identifier', but that ends up looking needlessly obscure.  In fact, if I could read the Label and (in my case) the WatchPaths from the calling environment, then several of my program options would disappear.
> 
> So I'm not thinking of the job parameters as _state_, quite, but as part of the program launch environment.  Rather than (argc, argv, environ), it's effectively (argc, argv, environ, plist).  That's not traditional unix, of course, but then launchd isn't traditional unix either.

It seems like you're basing a ton of behaviors simply on the job's label. Why do they have to be based on that? That said, I think it's reasonable to export the job's label in an environment variable or something. But plist is not there as part of the program's environment. It *defines* the program's environment.

Also, I can see how WatchPaths are clumsy in this case, but then again, the entire mechanism of WatchPaths is clumsy. You're virtually guaranteed to miss modifications a certain amount of the time, and you have no guarantee that the write which triggered the modification event left the file in a consistent state anyway. 

>> If you need to modify your program's behavior, you should specify different arguments or a different environment in the plist. That is what those entries are for.
> 
> Indeed, but in this case the information being communicated is information about the plist itself, which seems... clumsy.  That in turn makes me suspect I'm doing something the Hard Way.
> 
> @Graham: thanks.  launch_data_dict_lookup looks like it would do the job, and demonstrates that Apple feel that the information is legitimately available in at least some circumstances. But the fact that it's not documented _anywhere_ I can find (other than being implicitly documented as part of Apple example code), makes me nervous of using it.
> 
> All the best,

Those interfaces are really only so that jobs can check in with launchd to obtain listening sockets. They were way too general at the outset.
-- 
Damien Sorresso
dsorresso at apple.com