[launchd-dev] Yosemite not starting a system launch agent

[Axel Luttgens]

> Le 23 juil. 2015 à 17:35, Damien Sorresso a écrit :
> 
> On 22 Jul, 2015, at 22:49, James Bucanek wrote:
>>> […]
>> In my case, the 'launchctl load ...' command is being executed via NSTask launched from a helper running as root, itself launched from a privileged helper service installed via SMJobBless. I don't know if this puts launchctl in the context of Background session of the user or in the root System session.
> 
> That is your problem. In that context, `launchctl load` will attempt to load your job as a daemon because it is running as root in the root Mach bootstrap. One thing that's critical to understand is that there's nothing about the contents of your plist which identifies it as a daemon or agent; the same plist can be loaded into multiple contexts. Each context can have sessions within it. As it turns out, the only place this matters is the per-user context, which has Background and Aqua.

Hello Damien,

Only those two contexts? No login context (or LoginWindow context, whatever it is called)?


> The intended effect of `launchctl load` and friends is determined by your calling context.
> 
> This is why the new bootstrap subcommand introduced in Yosemite takes an explicit parameter identifying the context you want to bootstrap the job into. Try changing your NSTask invocation in your helper tool to this:
> 
> launchctl bootstrap user/$UID /path/to/plist

Yes, I noticed this was working while experimenting around James’ plist; but this happened only intuitively, by guessing that the bootstrap subcommand could well have been devised so as to bypass the calling context.

Could it be that such matters are already extensively/systematically documented somewhere, and that I just missed it (shame on me)?


> On earlier versions of OS X, this should also work:
> 
> launchctl asuser $UID launchctl load /path/to/plist

I’ll take the opportunity of the above for asking another question.

From the launchctl(1) man page:

In the discussion of the -S sessiontype option, three "contexts" (or "sessions", which seems to be taken as a synonym) are distinguished at the per-user level:
	1a. Aqua
	1b. Background
	1c. LoginWindow

In the discussion of the asuser subcommand, one may read about:
	2b. the target user’s bootstrap

In the description of the various target domains, one has:
	3a. login/<asid>, gui/<uid> 
	3b. user/<uid>

May it be said that, for example, 1b, 2b and 3b are covering the same concept, in spite of quite different terminologies?

TIA,
Axel