On 22 Jul, 2015, at 22:49, James Bucanek <subscri...@gloaming.com> wrote: >> Damien Sorresso <mailto:dsorre...@apple.com> July 22, 2015 at 6:19 PM >> James, >> >> Some replies inline... >> >> On 22 Jul, 2015, at 17:46, James Bucanek <subscri...@gloaming.com >> <mailto:subscri...@gloaming.com>> wrote: >>> Damien, >>> >>> Thanks for the suggestion, and apologies for the tardy reply; I just got >>> buried under twenty other to-do items that were higher on the list. >>> >>> I tried removing the LimitLoadToSessionType entry from my agent's plist, >>> but it doesn't make any difference. When trying to install it as a >>> system-wide agent, the process still doesn't start. >> >> In launchd's lexicon, "system-wide agent" is a conflict of terminology. >> System-wide things are, by definition, daemons. Agents are things which run >> on a per-user basis (cf. launchd(8)). So the real question is about the >> desired lifecycle of your job. Do you want it to run when a user logs in and >> to go away when the user logs out? Or do you want it to be available >> regardless of any user being logged in? > That's the problem; I don't know what to call them. It's an agent, but it's > an agent for all users (/Library/LaunchAgents) to distinguish it for > exclusively for an individual user (~/Library/LaunchAgents). And it should > run in the context of the user's bootstrap, not just within the GUI login. >>> My reading of LimitLoadToSessionType would lead me to believe that it's >>> applicable to my service, which *is* an agent. It runs as a regular user, >>> and the docs would indicate that this property is just a hint to the load >>> balancer on how to constrain its use of CPU/memory/IO. It doesn't make >>> sense that it would keep the process from starting in the first place. >> >> Wow, no that's not at all what that key is for. Please file a bug explaining >> how the documentation misled you into that impression so we can make it >> clearer! > I think I got this confused with ProcessType. Both have a "Background" type. > > I'll file a bug report on the docs, but one problem that I run into is that > terms are often never defined. For example, the LimitLoadToSessionType > section in man 5 launchd.plist describes it thusly: > > "LimitLoadToSessionType <string or array or strings> > This configuration file only applies to sessions of the type(s) > specified." > > But the descriptions of what "type(s)" can be is never defined or explained > in the man pages for launchd.plist, launchctl, or launchd. I'm sure the > description of what LimitLoadToSessionType does is accurate, but I still left > wondering what values are valid or what they mean. :)
Yes, please file a documentation bug. This could be made clearer. >> Session types are basically collections of certain kinds of jobs. The "Aqua" >> session is all the jobs associated with a graphical login on the console. By >> default, if your job is an agent, it is loaded into the Aqua session. (That >> is, if no LimitLoadToSessionType key is present.) >> >> The Background session is a collection of jobs that can run on behalf of a >> user even if that user is not logged in at the graphical console. They might >> be doing things like performing Spotlight indexing on that user's home >> directory even when that user isn't logged in for example. > What I want, and I think that's what I've configured in the .plist, is a > per-user Agent running in the Background session, for all users. The .plist > is placed in /Library/LaunchAgents and the LimitLoadToSessionType is set to > Background. (See my earlier message. It has all the details.) >> >> So if you have a vanilla Terminal prompt and do a `launchctl load`, your >> plist will attempt to load in the Aqua session. If that service has >> LimitLoadToSessionType set to "Background", then that load will fail because >> it's attempting to load in the Aqua session and your service has expressed >> that it should only load in the Background session. > 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. 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 On earlier versions of OS X, this should also work: launchctl asuser $UID launchctl load /path/to/plist -damien
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/launchd-dev
