July 2015 - launchd-dev - lists.macosforge.org

launchd logging?
by Nathan Bailey 30 Jul '15

30 Jul '15

Hi all, All of my launchd jobs log to err and out files, but I'd like to get a better sense of how they are running (or not). I saw there used to be launchd logging levels: http://apple.stackexchange.com/questions/169404/set-launchd-log-level but these have gone away in 10.10. Is there any plans to reintroduce them? thanks! Nathan

1 0

Yosemite not starting a system launch agent
by James Bucanek 23 Jul '15

23 Jul '15

Greetings, Here's my problem in a nutshell: I have a simple scheduler daemon that runs in the background for logged in users. The problem is that it won't start when installed in Yosemite (seems to start in all previous versions of OS X that use launchd). Here's what my program does: 1) I install the com.qrecall.sheduler.plist in /Library/LaunchAgents/ (with the correct ownership and access privileges). 2) launchctl load -S Background /Library/LaunchAgents/com.qrecall.scheduler.plist (successful) 3) launchctl start com.qrecall.scheduler (exits with status 1) And the scheduler process is NOT started. All attempts to get it started through launchctl have failed. However, I know that it's installed because if you simply restart the system the scheduler deamon starts running like a champ. Now ... I know what you're going to say: "Dude! You should be using the new launchctl commands introduced in 10.10!" Tried that. I can't seem to get anywhere with it. Basically, I don't know what I'm doing. I've read the man page for the new launchctl about 20 times and I'm still not sure how I should be using it. For per-user agents, it seems pretty obvious that you would bootstrap and address the service in the user/login/gui domain (i.e. launchctl enable user/501/com.qrecall.scheduler). But I don't understand how to treat a system-wide user agent that should be installed in /Library/LaunchAgents. Through trial and error, I've discovered that I can address the current user's instance of the scheduler process for commands like "kill". So this command works: launchctl kill TERM user/501/com.qrecall.scheduler It sends a TERM signal and the daemon restarts. However, I can't find anyway to use the bootstrap command to install it, the enable command won't start it, and the kickstart command says there's no such service. It would seem to make sense that a system-wide agent would have to be installed in the system domain, but this command: sudo launchctl bootstrap system /Library/LaunchAgents/com.qrecall.scheduler results in the error "/Library/LaunchAgents/com.qrecall.scheduler.plist: Service cannot load in requested session" Attempts to use any other domain in the command result in a syntax error, so I'm completely stumped as to how the service should be installed. I've figured out the I can enable and disable the per-user instance, but it has no effect on the running process. In other words, disabling won't halt the service and enabling it won't start it. And don't get me started on unbootstrap, which doesn't appear to be implemented. So, at this point I have my feet planted firmly in mid-air... James Bucanek

3 11

launchctl bsexec and El Capitan follow up Q
by Gregory Neagle 21 Jul '15

21 Jul '15

In order to install some Adobe products when there is no GUI user currently logged in, it has been necessary to use `launchctl bsexec` to run the installation process in the same context as the loginwindow. Adobe documents this technique here: http://www.adobe.com/content/dam/Adobe/en/devnet/creativesuite/pdfs/AAMEE_E… <http://www.adobe.com/content/dam/Adobe/en/devnet/creativesuite/pdfs/AAMEE_E…> Here is an example from that document: sudo launchctl bsexec `ps auwwx |grep [l]oginwindow | awk '{ print $2 }'` Adobe\ AIR\ Installer.app/Contents/MacOS/Adobe\ AIR\ Installer -silent With the SIP and launchd changes in El Capitan, is there an equivalent? Though I would hope Adobe would fix their installers to not need these silly hacks, even if they do in the future, that’s not going to help the install of current and recent releases. -Greg

2 1

Loading LaunchAgents for users in postinstall
by Per Olofsson 19 Jul '15

19 Jul '15

When an installer package contains a LaunchAgent we typically try to load it into any current user sessions, to avoid requiring a logout or restart. Through trial and error we've arrived at using launchctl bsexec with chroot in a loop like this: if [[ "$3" == "/" ]]; then # Load agent for all logged in users. for pid_uid in $(ps -axo pid,uid,args | grep -i "[l]oginwindow.app" | awk '{print $1 "," $2}'); do pid=$(echo $pid_uid | cut -d, -f1) uid=$(echo $pid_uid | cut -d, -f2) if [[ "$uid" -ne 0 ]]; then launchctl bsexec "$pid" chroot -u "$uid" / launchctl unload "$AGENT" launchctl bsexec "$pid" chroot -u "$uid" / launchctl load "$AGENT" fi done fi It's not perfect but it got the job done, but it looks like it breaks in the 10.11 betas if SIP is enabled (launchctl exits with code 5). Is there a better/proper/supported way of loading LaunchAgents for users in a background script running as root? -- Per Olofsson, IT-service, University of Gothenburg

4 5

Re: [launchd-dev] Loading LaunchAgents for users in postinstall
by Hofi 18 Jul '15

18 Jul '15

As this solution (launchctl bsexec chroot) finally started working only in 10.10 and was broken almost till final, release version of Yosemete I suggest you to wait for the final release and file a bug report to apple. Hopefully they will fix it ASAP. ——————————————————— Hofi – Istvan Hoffmann On 7/17/15, 17:11 , "Per Olofsson" <launchd-dev-bounces(a)lists.macosforge.org on behalf of per.olofsson(a)gu.se> wrote: >When an installer package contains a LaunchAgent we typically try to load it into any current user sessions, to avoid requiring a logout or restart. Through trial and error we've arrived at using launchctl bsexec with chroot in a loop like this: > >if [[ "$3" == "/" ]]; then > # Load agent for all logged in users. > for pid_uid in $(ps -axo pid,uid,args | grep -i "[l]oginwindow.app" | awk '{print $1 "," $2}'); do > pid=$(echo $pid_uid | cut -d, -f1) > uid=$(echo $pid_uid | cut -d, -f2) > if [[ "$uid" -ne 0 ]]; then > launchctl bsexec "$pid" chroot -u "$uid" / launchctl unload "$AGENT" > launchctl bsexec "$pid" chroot -u "$uid" / launchctl load "$AGENT" > fi > done >fi > >It's not perfect but it got the job done, but it looks like it breaks in the 10.11 betas if SIP is enabled (launchctl exits with code 5). Is there a better/proper/supported way of loading LaunchAgents for users in a background script running as root? > >-- >Per Olofsson, IT-service, University of Gothenburg > >_______________________________________________ >launchd-dev mailing list >launchd-dev(a)lists.macosforge.org >https://lists.macosforge.org/mailman/listinfo/launchd-dev

3 2