Damien Sorresso <mailto:dsorre...@apple.com>
November 5, 2015 at 3:43 PM
On 5 Nov, 2015, at 14:23, James Bucanek <subscri...@gloaming.com
<mailto:subscri...@gloaming.com>> wrote:
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.
I'm trying. :)
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.
Honestly, I had always assumed that any
authentication/login/mounting/decrypting would have been handled in
login's Aqua session, not the user's Aqua session. But if that's where
it's happening, I can see some of the chicken-and-egg problems.
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.
Thanks, that makes (a lot more) sense now.
OK, one last question: Is it ever the case that the home
directory/mountpoint might disappear *after* a user's Background and
Aqua session is created, say when they log out?
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.
There's a possibility I don't have to get that ugly, but I might look
into implementing something like that ... but only if the answer to the
earlier question is "never."
The principle purpose of my app is backups. If the user's home directory
is going to unmount again when they log out, trying to perform a backup
at that point is pretty useless, so worrying about how to keep the
scheduler running int the background session under those circumstance
would be moot.
James
_______________________________________________
launchd-dev mailing list
launchd-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/launchd-dev
