[launchd-dev] Cause of "Service cannot load in requested session"?

[Damien Sorresso]

On 5 Nov, 2015, at 14:23, James Bucanek <subscriber at gloaming.com> wrote:
> Damien,
> 
> Thanks for the feedback. Replies inline...
> 
>> Damien Sorresso <mailto:dsorresso at apple.com>  November 5, 2015 at 9:32 AM
>> James,
>> 
>> Answers inline...
>> 
>> On 4 Nov, 2015, at 21:44, James Bucanek <subscriber at gloaming.com> <mailto:subscriber at gloaming.com> wrote:
>>> Greetings,
>>> 
>>> I have a user agent installed in the "Background" session that isn't starting up on one system.
>> The Background session is typically only useful for agents which you want to run "as the user" independently of whether that user is logged in. In the strictest terms, you can't even rely on the home directory for that user being available. So you should be sure that this is the session you really want.
> I understand. This is exactly the session I want. My product has an option ("Start and run actions when logged out") that allows you install the scheduler agent the "Background" session so that backups and other maintenance can be performed even when logged out (or because you've logged out).

Okay, just as long as you understand the implications.
>>> My customer is running OS X 10.11.1. I have this software running on hundreds of El Capitan systems, but for some reason this user agent won't start when the user logs in.
>>> 
>>> I've found two things that are suspicious. First, a message like this appears in the console log:
>>> 
>>> system.log: Oct 31 17:45:05 UsersMac otherbsd[488]: Failed to bootstrap agent: path = /Users/theuser/Library/LaunchAgents/com.qrecall.scheduler.plist, error = 134: Service cannot load in requested session
>>> 
>>> I was really hoping that someone could tell me what error 134 means.
>> The string representation of the error is printed right after it. Also, you can decode launchd's error codes with the `launchctl error` subcommand; in this case it'll print "Service cannot load in requested session".
>> 
>> What this means is that one of launchd's helpers, otherbsd, tried loading the com.qrecall.scheduler service into the user's Aqua session. The plist almost certainly specifies a LimitLoadToSessionType entry which says it can only load in the Background session. So launchd refuses to load the service.
> So that begs two questions:(1) Why is the service being loaded in the Aqua session? (That might be an artifact of something that's loading it into a session it's excluded from. I get that, and I suppose that could be ignored.)
> 
> (2) More importantly, why isn't it being loaded into the Background session when that session is created?
> 
> I'm surprised that you say that the home folder might not be available when the Background session is created. How is that possible? The user agent configuration file (~/Library/LaunchAgents/com.qrecall.scheduler.plist) is _inside_ the home folder. How would launchd load an agent service *before* the configuration file that defines that service is readable?

This gets complicated. First off, Background agents cannot rely on the presence of the user's home directory because there is code that executes only in the GUI login path which may be responsible for making that home directory available. Think NFS home directories or OG FileVault, which both require the user to enter her password at the login window to mount/decrypt the home directory. In either of those scenarios, without the user's secret, the home directory is inaccessible.

For this reason, launchd cannot actually support loading Background agents from the user's home directory. This is what you're hitting.

To give you a little more background on what's happening, launchd has to use a helper (otherbsd) to sniff out agents from the user's home directory because it itself cannot actually safely resolve a user's home directory location. The calls to do this (getpwnam(3) and friends) might wind up doing IPC to opendirectoryd, which launchd is responsible for launching, which would create a layering inversion.

So what it does instead is spawn its little otherbsd helper to go off, find the user's home directory, and snarf the agents contained therein. But this agent is there specifically to load stuff into the Aqua session. So when it gives launchd a plist that has its loads limited to the Background session, launchd says "No you're in the wrong session", hence that error message.

> Anyway, I really hope that's never true, because my service has always depended on resources in the home folder (preferences, cache, documents, and such). And in this case, the service executable is also stored in ~/Library/Application Support/, so the home folder has to be available if it's going to start (and it always starts on other systems).

Unfortunately, while it may not be a very common case, it is nonetheless a case that we must deal with sanely and support.

> But I'll also ask the user if they're doing anything "clever" with their home folder.
> 
> Thanks for any insight,

Something ugly you could do:

Have another plist inside ~/Library/LaunchAgents that does not have the LimitLoadToSession key set which runs a script which does

launchctl load -S Background ~/Library/LaunchAgents/com.qrecall.scheduler.plist

That will target the load to the background session upon the user's GUI login, and the agent will continue to be available after logout, but it will not be available until the user logs in at least once on the GUI.
-damien


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/launchd-dev/attachments/20151105/8a0829cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3327 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/launchd-dev/attachments/20151105/8a0829cd/attachment-0001.p7s>