Currently Being ModeratedMay 7, 2012 2:48 PM (in response to Jonathan Pool)
As I understand it, you should place your plist file in LaunchDaemons rather than LaunchAgents if you only want it to run when certain parameters are met. Once the plist file is in that directory, run 'launchd load /System/Library/LaunchAgent/<your file>.plist'
Currently Being ModeratedMay 7, 2012 2:57 PM (in response to Mike Mesford)
Thanks. As I understood the documentation, the distinction is merely between plist file owners: If root owns the plist file it's a daemon and if any other user owns it it's an agent.
Loading the file with launchctl worked, but the job was launched right after it was loaded, despite RunAtLoad not being in the plist.
Currently Being ModeratedMay 7, 2012 3:16 PM (in response to Jonathan Pool)
Well, I can't find where I read that so I must've made it up. My re-reading of the documentation agrees with your interpretation. So I'll go back to trying to understand the "exec format error" that led me to this discussion in the first place.
Currently Being ModeratedMay 7, 2012 6:19 PM (in response to Jonathan Pool)
ok, a short bit of testing and I understand why the utility launches immediately. QueueDirectories checks at load whether the directories in question contain anything and triggers the utility if they do. even an invisible .DS_Store file is enough, and it will keep the utility alive until the folder is empty again. that explains the start-at launch problem.
I'm not seeing the cause of the exec error yet. a quick google search tells that this is a non-specific error (e.g., what the interpreter says when it's grumpy about something it hasn't been programmed to expect). a common cause seems to be spurious invisible/whitespace characters at the beginning of the script file.
WatchPaths jobs do not recurse. as I suggested, better to do periodic syncs.
Wow. I don't know how anybody would know that QueueDirectories does this. You have made its behavior clear. Thanks very much. Now I suggest that the man entry be changed to describe that behavior. Something like:
QueueDirectories <array of strings>
This key will make the job start at load if any of the paths is a non-empty directory and will keep the job alive as long as any of the paths is a non-empty directory. (A directory counts as non-empty if it contains an invisible file or contains an empty directory.)
Thanks much for discovering this.
Message was edited by: Jonathan Pool