Hello,
I want to create a Launch Agent that triggers an executable upon changes in the /Applications folder.
The launch agent is normally a loaded but not running, and by adding /Applications
to the WatchPath parameters in the plist, launchd is supposed to trigger the process, that will run and exit once done.
Sadly this seems not to be working uniformly. The script only works on one machine, in the the others the execcutable is never run. There seem not to be any meaningful differences in the launchd or system logs.
The same identical plist works perfectly when changing something in the user's ~/Applications folder. The script does its job and logs are visible.
Is there an undocumented limitation specifically for the /Applications
folder that prevents luanchd to observe it in the WatchPaths? Maybe SIP not allowing access? But why does it work on my machine?
Here is an example of the ~/Library/LaunchAgents/com.company.AppName.LaunchAgent.plist
:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>AssociatedBundleIdentifiers</key>
<string>com.company.AppName</string>
<key>KeepAlive</key>
<false/>
<key>Label</key>
<string>com.company.AppName.LaunchAgent</string>
<key>ProgramArguments</key>
<array>
<string>/Users/username/Library/Application Support/com.company.AppName/Launch Agent.app/Contents/MacOS/LaunchAgent</string>
</array>
<key>RunAtLoad</key>
<false/>
<key>WatchPaths</key>
<array>
<string>/Users/username/Applications</string>
<string>/Applications</string>
<string>/Network/Applications</string>
</array>
</dict>
</plist>
With the executable being a standard app bundle in /Users/username/Library/Application Support/com.company.AppName/Launch Agent.app
Thank you
The script only works on one machine, in the the others the execcutable is never run.
I most commonly see problems this this caused by the user privileges set in System Settings > General > Login Items & Extensions.
A good way to isolate this is to manually start the job. For example, if you’ve loaded the job into a specific user’s GUI context, you can launch Terminal and run this:
% launchctl start com.company.AppName.LaunchAgent
You’ll see one of two things:
-
The job fails to start — In this case the above-mentioned privilege is the most likely cause.
-
The job starts — That rules out the above-mentioned privilege as a concern and you can then focus on
WatchPaths
.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"