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

[James Bucanek]

Greetings,

I have a user agent installed in the "Background" session that isn't 
starting up on one system.

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

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

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