27

I have a launchd daemon placed in ~/Library/LaunchAgents that worked well in Mavericks. But it won’t start in Yosemite public beta. The daemon plist is like this (my username is darksair with UID 501)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.darksair.retrmail</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Users/darksair/bin/retrmail.py</string>
    </array>
    <key>KeepAlive</key>
    <false/>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>LaunchOnlyOnce</key>
    <false/>
    <key>UserName</key>
    <string>darksair</string>
    <key>ProcessType</key>
    <string>Standard</string>
    <key>EnvironmentVariables</key>
    <dict>
      <key>PATH</key>
      <string>/Users/darksair/Python/bin:/Users/darksair/Python3/bin:/Users/darksair/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>StandardOutPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
  </dict>
</plist>

Basically it is supposed to run ~/bin/retrmail.py every 5 minutes.

I notice that in Yosemite launchd is upgraded to 2.0, and launchctl has new commands. I tried

sudo launchctl kickstart user/501/org.darksair.retrmail

and it said

Could not find service "org.darksair.retrmail" in domain for uid: 501

I also tried the old school

sudo launchctl load ~/Library/LaunchAgents/retrmail.plist

and it said

/Users/darksair/Library/LaunchAgents/retrmail.plist: Path had bad ownership/permissions

The file is owned by me and the staff group. I tried both permission 644 and 600 with the same error.

So does anyone know how to properly fire up a launchd daemon in Yosemite?


UPDATE: Looks like my launch agent file has to be owned by root:wheel. After I chown, I tried

sudo launchctl load ~/Library/LaunchAgents/retrmail.plist

and it didn’t issue any error. And I think my deamon is running properly. I’ll leave this question open because I remember the launchd document clearly states that the launch agent file can be owned by the user running the daemon.


UPDATE2: No it wasn’t running properly. It got run only once, but not again, as if it was unloaded.


UPDATE3: I upgraded to Yosemite public beta 3, and changed my agent to this

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.darksair.retrmail</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Users/darksair/bin/retrmail.py</string>
    </array>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>UserName</key>
    <string>darksair</string>
    <key>EnvironmentVariables</key>
    <dict>
      <key>PATH</key>
      <string>/Users/darksair/Python/bin:/Users/darksair/Python3/bin:/Users/darksair/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>StandardOutPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/darksair/logs/retrmail.log</string>
  </dict>
</plist>

I reloaded this agent, and I think now it is working properly. I’m still leaving this question open because I don’t know what’s wrong with my previous plist.


In conclusion, what I found is I have to change the owner of the plist to root:wheel in order to load it.

  • Does this work in Yosemite final? – TJ Luoma Oct 24 '14 at 11:53
  • @TJLuoma: yes. As long as the plist is owned by root:wheel. – MetroWind Dec 9 '14 at 21:07
21

From man launchctl

Note that per-user configuration files (LaunchAgents) must be owned by root (if they are located in /Library/LaunchAgents) or the user loading them (if they are located in $HOME/Library/LaunchAgents). All system-wide daemons (LaunchDaemons) must be owned by root. Configuration files must disallow group and world writes. These restrictions are in place for security reasons, as allowing writability to a launchd configuration file allows one to specify which executable will be launched.

Fix is

sudo chmod 600 /Library/LaunchDaemons/x.plist
sudo chown root /Library/LaunchDaemons/x.plist
  • 2
    “or the user loading them” <— This is the part I have problem with. – MetroWind Dec 9 '14 at 22:06
  • 2
    I'm not a unix guy, but it says "disallow group and world writes". Since it may still need to be read, shouldn't it be chmod 644? – Jason Dec 30 '14 at 22:50
5

Strangely enough, using sudo was your problem. By using sudo, you were no longer yourself, so you were not the owner of your own file. Remove sudo, repeat the command and it should load just fine. Sorry for the philosophical approach to it all.

4

Found the solution.

The correct command in this case is

launchctl bootstrap gui/501 ~/Library/LaunchAgents/retrmail.plist

And to unload,

launchctl bootout gui/501 ~/Library/LaunchAgents/retrmail.plist

Don't know why launchctl load requires root though, but load/unload is deprecated anyways.

  • Man page lists bootout not bootcut. I think autocorrect got you since on my machine it changes bootout to bootcut. – Steve Moser Mar 12 '17 at 1:44
  • @MetroWind I am getting Could not find domain for Code=112 error with above command. its not consistent. any clue ? – Parag Bafna Nov 3 '17 at 5:16
  • Did you still need the chmod & chown? – Itachi Jan 22 at 9:26
  • @Itachi, no. Leaving the default owner and permission should be fine. – MetroWind Jan 23 at 19:53
  • @ParagBafna, I’m not sure. Maybe your UID is not 501? – MetroWind Jan 23 at 19:54
3

Ran into this too, trying to use user, not root owned .plist (as one should be able to do)

$ load ~/Library/LaunchAgents/com.blash.blah.plist
Could not find domain for 

I was ssh-ed into this machine remotely while I was NOT logged in at the console (headless) which seemed to be my issue - at least the user-managed services needs the user is logged in on the main screen (I ended up doing loggin-in via remote-management as this is a headless machine)

IMO, if you want this to run even if you are not personally there to log in your options are:

  • Make your account login automatically (note the security implication, also without the UserName tag as noted in one of the answers)

  • Make the files root owned as noted in the various suggestions (setting effective the user back to yours with UserName as you already have)

  • 2
    Thank you, so much. I have found solution in your answer. – Retraut Dec 3 '18 at 14:29
2

Here's a silly idea.

I just had the same error, also after having upgraded to Yosemite. I mistakenly assumed it meant bad ownership/permissions on the .plist file, when in fact, for some reason the binary that I was referencing in the plist (in my case cassandra), had lost its executable bit.

chmod +x'ing it fixed it.

Probably not your problem, but might be worth a shot :)

  • This does not apply to my case though. My executable does have the x permission bit. But thank your for the answer anyway. Hope it may help some other people. – MetroWind Aug 24 '14 at 20:41
2

Remove the UserName key and string.

The issue is that the UserName key can only be used if the process is started by root. It can only be started as root if the plist is owned by root. Basically, the process is started by root and then is suid'ed to the user specified. If you want this process to run as yourself, put the plist in your ~/Library/LaunchAgents folder and remove the UserName key.

1

Were you trying to manually reload an agent that had user permissions? I don't entirely understand why any of this is required, but I believe that you need to be attached to your users domain (which it seems that you are not attached to when you run as root). Using these functions to reattach worked for me.

function as_user {
    local user="$1"
    local user_pid=$(ps -axj | awk "/^$user / {print \$2;exit}")
    local command="sudo launchctl bsexec $user_pid sudo -u '$user' $2"
    echo "Running:"
    echo "$command"
    eval $command
}

function as_current_user {
    as_user "$(whoami)" "$*"
}

function reload_agent {
    as_current_user launchctl unload "$1"
    as_current_user launchctl load "$1"
}

You would use this as follows:

reload_agent ~/Library/LaunchAgents/com.hw.helloworld.plist

The bsexec puts you back in your domain, and lets you add the task as a user launchagent.

  • It says: /Users/darksair/Library/LaunchAgents/retrmail.plist: Operation already in progress. At this point my questions are basically: why didn’t the kickstart command work? And why do I have to set the plist ownership to root…? – MetroWind Oct 22 '14 at 18:54
  • 1
    You should NOT set the owner of your plist file to be root; everything in ~/Library/LaunchAgents should be owned by the user to whom that directory belongs. I got the Operation already in progress thing when I did not unload the command before I loaded it. Are you using the function that I provided? – imalison Oct 22 '14 at 20:12
  • Yes. I was using your functions. And I did unload the plist first… – MetroWind Oct 23 '14 at 1:39
  • I just tried loading the first plist you provided and it worked for me. What permissions are set for the file? – imalison Oct 23 '14 at 6:19
  • This is an incredible piece of code for so many things. I'm using a mixture of puppet and custom bash scripts to manage many different macOS devices, and random issues because the security audit session or user domain isn't correct are so common. Great work! – Andrew White Jun 30 '17 at 1:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.