29

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.

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

8 Answers 8

22

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
3
  • 2
    “or the user loading them” <— This is the part I have problem with.
    – MetroWind
    Dec 9, 2014 at 22:06
  • 3
    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, 2014 at 22:50
  • 1
    Note that the file OP talks about is in fact in -/Library, not /Library. So OP may choose: Either chown the file, and run sudo launchctl, or leave the ownership as-is, and run launchctl (without sudo)
    – Qw3ry
    Mar 24, 2021 at 12:03
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.

5

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.

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

1
  • 2
    Thank you, so much. I have found solution in your answer.
    – Retraut
    Dec 3, 2018 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 :)

1
  • 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, 2014 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.

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

5
  • 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, 2014 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, 2014 at 20:12
  • Yes. I was using your functions. And I did unload the plist first…
    – MetroWind
    Oct 23, 2014 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, 2014 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! Jun 30, 2017 at 1:11
0

In case it helps anyone, I was seemingly unable to resolve this issue (on macOS Catalina 10.15.6) by changing permissions on files because my home folder is located on an external drive, and that volume in MacOS had the "Ignore ownership on this volume" setting enabled.

To fix this I first had to, as an administrator user, uncheck the "Ignore ownership on this volume" checkbox in the Finder "Get Info" (command-I) menu for the drive.

Then, after running

chown myuser ~/Library/LaunchAgents/myplist.plist
chmod 600 ~/Library/LaunchAgents/myplist.plist

(chmod may not have been necessary, since it already had 644 permissions)

I was finally able to run

launchctl load ~/Libary/LaunchAgents/myplist.plist

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .