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

Damien Sorresso dsorresso at apple.com
Thu Nov 5 08:32:23 PST 2015


James,

Answers inline...

On 4 Nov, 2015, at 21:44, James Bucanek <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.

> 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.

> The other, really strange, thing is that when I look at the log output of the com.qrecall.scheduler process (when it does get started, usually as a result of a launchctl load command), I sometimes find that the very first thing it logs is the receipt of a SIGTERM signal. That means that it has received a SIGTERM even before its run loop has started. The result is that the agent starts up and then immediately shuts down.

I do not believe that is related here -- a failure to load the service indicates that the process will never run at all. So obviously it will not be able to receive SIGTERM.

> Context (if it's important):
> 
> This service is installed as an alway running user agent, in the "Background" session. This is so the process will continue to run even after the user has logged out. (The service can schedule backup and other maintenance tasks to run while the user is logged out.)
> 
> To make sure the process is running even before the user logs in for the first time, I install a tiny "kicker" system daemon. The "kicker" has a list of UIDs of the users that have installed the background scheduler. At startup, the "kicker" simply make a bootstrap call that causes the bootstrap for that user to be created. This, in turn, initializes the user's bootstrap, which involves starting all of its background processes.
> 
> I suspect that console message is being logged around this time (but it's hard to tell exactly just by looking at the logs).

In this case, the console message is being logged when the user attempts to log in. The otherbsd helper does not run when the Background session gets bootstrapped.
-damien

> I've had the user switch to using a regular user agent ("Aqua" session, and no kicker daemon), and things seem to be working.
> 
> Any insight would be helpful.
> 
> TIA,
> 
> James
> _______________________________________________
> launchd-dev mailing list
> launchd-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/launchd-dev

-------------- 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/b2600966/attachment-0001.p7s>


More information about the launchd-dev mailing list