LaunchAgent help

New Contributor III

Disclaimer I'm trying to pick up learning both Bash scripting and LaunchAgents to make my job easier (and to take more advantage of Jamf Pro), so I'm quite the noob with it.

I can't get the script to which my LaunchAgent is pointing to run at login. I've tested the script, checked permissions on it, and manually ran it on a target computer, and all is well with the script itself. That leads me to believe that the LaunchAgent either isn't loading or isn't working properly. I've got the .plist stored in /Library/LaunchAgents. Here's the contents of the .plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

and here is the script itself:


dockutil --add /Applications/Microsoft --allhomes --no-restart

dockutil --add /Applications/Microsoft --allhomes --no-restart

dockutil --add /Applications/Microsoft --allhomes --no-restart

dockutil --add /Applications/Microsoft --allhomes --no-restart

dockutil --add /Applications/Microsoft --allhomes --no-restart

dockutil --add /Applications/Google --allhomes --after Safari --no-restart

dockutil --add /Applications/Self --allhomes --position end --no-restart

dockutil --remove 'Contacts' --allhomes --no-restart

dockutil --remove 'Maps' --allhomes --no-restart

dockutil --remove 'iBooks' --allhomes --no-restart

dockutil --remove 'Siri' --allhomes

Any ideas why it won't load?


Valued Contributor II

Do you need a full path to dockutil? Often you don't have full environment variables when running a LaunchA. /usr/local/bin/dockutil. Type 'which dockutil' to see where it is.

Also, put a little debug line in the top of your script - like 'touch /tmp/itStarted.$$' then you can login and look in /tmp/ to see if that file exists. Then you know your script is running, but dockutil line isn't doing what you expect. if you dont' have 'itStarted' file, then you know the script isn't executing.

Legendary Contributor III

What about the permissions and ownership on the LaunchAgent plist? That's actually more important than permissions on the script. All launchd jobs should have an owner and group of root and wheel respectively and the POSIX permissions should be 644. That's owner read and write, group and other/world read only.

Outside of that, regarding the script, make sure it has the executable flag set on it, since you're calling the script by path only, not by putting a sh in front, not that it should need it mind you. It just needs to be executable and the correct owner/group/permissions on the LaunchAgent plist. Also, I would consider putting the full path to the dockutil utility in your script. I'm finding more and more with launchd jobs that they work better if you're explicit about paths to binaries and such.

Valued Contributor III

A few things.
1: as @mm2270 said, the permissions and ownership have to be exactly right for it to work do a

ls -l /Library/LaunchAgents

and make sure it matches the rest of them.

2: I found dock modifications sometimes happen to early when called with a LaunchAgent and putting a small delay at the start might help.

3: I am not sure why but for some reason I have always done my LaunchAgents like this in the part where it calls the actual script.


To be honest though this probably just stems from the fact I will have looked at an existing one the first time I created one and it has always worked so thats how I have continued to do it.

Legendary Contributor III

@Look Both <key>Program</key> and <key>ProgramArguments</key> and the associated <array> tags are valid syntax. "Program" can be used when you only have a single command to run, like the path to a script. "ProgramArguments" must be used if you syntax with multiple arguments, which each going on it's own line. For example:


Valued Contributor II

I'll ask the bigger question, Is there a reason you "have to" manage the users dock? I would guess that there are security related setting that are many times more important .. like

While I do understand that it's "nice" and possible that a manager asked you too, managing any setting with a third party utility is risky. Is the 3rd party utility secure, will it alway be available and what are the chances Apple updates breaks the utility?



Contributor III

@arpierson We manage our lab docks using dockutil. I have a script attached to a policy (scoped to a "Labs" smart group) that runs at login. The policy is also made available offline, so if for some reason the Mac drops its network connection, the script will still run.

Doing it this way gives me the ability to change the script to add/remove apps when necessary!

Hope this helps.