James, Answers inline...
On 4 Nov, 2015, at 21:44, James Bucanek <subscri...@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@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/launchd-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/launchd-dev
