launchd plist xml to run job several times a day?

al1776 wrote:

So where do I put the plist for a job to be run as root? in ~/library/launch... (user) or in /library/launch... (system.)?

What exactly is an "on demand" job?

How do I change when a job runs? Yes, chage the plist... but do I have to re-launch it?

ok, process broken down in detail:

a launchd plist is essentially a configuration file. it does (effectively) three things:

• sets up a label to identify the job in launchd
• points to a script or utility that will be run when the conditions are right
• establishes a set of conditional triggers that outline when the script or utility should be run

There are a number of different triggers that can be used:

• StartInterval - ever X seconds
• StartCalendarIntervel - at particular dates and times
• OnLoad - when the plist is loaded into launchd
• OnMount - when a file system is mounted
• KeepAlive - re-run the process whenever the process quits (with conditions)
• etc.

OnDemand is deprecated - basically it's the same as KeepAlive (OnDemand/true = KeepAlive/false). don't use it.

the way the process works is that the launchd plist is loaded into launchd (at system reboot, login, or when launchctl load is run). launchd reads it as a configuration plist and creates a launchd job based on the information it finds. This job stays active until removed.

if you want to change the configuration, do this.

1. modify and save the plist file
2. remove the currently running job (shutdown, log out, launchctl remove label or launchctl unload plist)
3. reload the modified plist file to create a new job (restart, log in, launchctl load plist)

if you want to test a job to see if it's working, use launchctl start label, which triggers the job to run the script or utility. then run launchctl list and look for the label name. it should look something like:

- 0 Label

the - might be a number if the script is still running (it's the process ID). the 0 means successful execution the last time the utility was triggered (a non-zero number means the script threw an error when run)

if there's no GUI then put the plist file in /Library/LaunchDaemons. that will run it as root in the background. If you find it throws errors that way, you might try it in /Library/LaunchAgents - that runs it with administrator privileges but in the login window of a user, so it can access aqua features. but this really sounds like a daemon to me, so...

In Apple's system-lingo: "A daemon is a program that runs in the background as part of the overall system (that is, it is not tied to a particular user). A daemon cannot display any GUI; more specifically, it is not allowed to connect to the window server." (see Tech Note 2083) It doesn't have to be a continuously running program, just one that doesn't interact with users directly. Your script will probably work in either location, mind you, so the distinction might be academic.

All enabled plists are loaded at restart or login. Enabled plists are plists in one of the three user-accessible launchd folders (already mentioned) which are not explicitly disabled by a Disabled key set to true (it's actually a little more complicated than that - the Disabled key in the plist is 'advisory', and the system stores the real enabled list in an undisclosed location - but it usually works). You only need to use launchctl if you are manually updating a plist and don't want to log out, or sometimes in super-tricky cases where you want to programmatically load a plist (in those cases you set the plist's Disabled key to true so it doesn't load, and then script launchctl to load it by override the Disabled key with the -F or -w options. probably TMI). it is set-it-and-forget-it.

There's no simple utility for this, I think, because not that many people use launchd directly, and those few who do tend to write plists, toss them in the correct folder, and forget about them. I have a applescript I use for loading and reloading plists which I keep in the script menu:

on run

tell application "Finder" to set theItems to the selection as alias list

relaunchd(theItems)

end run

to relaunchd(theItems)

repeat with thisPlistFile in theItems

tell application "Finder" to set containerName to displayed name of container of thisPlistFile

if containerName is in {"LaunchAgents", "LaunchDaemons"} then

set thePath to quoted form of (POSIX path of thisPlistFile)

do shell script "launchctl unload " & thePath

do shell script "launchctl load " & thePath

end if

end repeat

end relaunchd

The difference between launchd and cron is that cron is (pardon me for putting it this way) a unix-geek tool: its language is highly compressed and symbolic. good for fast typing in a command-line environment, bad because a single mistyped character can become a major headache to diagnose and fix. Launchd (like many things Apple) is much more verbose and 'natural language'-like, which means a lot more typing but a generally more user-friendly experience (once you wrap your head around it). tradeoffs vs. tradeoffs.

That's two questions. 😝

• do not put anything in the /System folder unless you know exactly what you're doing - that is for Apple's use. Use /Library/LaunchAgents or /Library/LaunchDaemons.
• launchd plist must be loaded as jobs to run, and must be removed as jobs to make them stop running. there are two ways to load a plist as a job
  1. reboot the system (or logout/login for user plists)
  2. remove/reload a script using launchctl in terminal (launchctl load /path/to/plistfile.plist, launchctl unload /path/to/plistfile.plist, launchctl remove job.label)

read man launchctl

Have you read the launchd plist documentation? In terminal type (copy/paste) the following line:

man 5 launchd.plist

I think the problem here is that you can run a tasks at fixed intervals so you can't do what you want with a single launchd item. But I don't think there is anything stopping you from writing two items, one to run every day at hour 10 and the other to run every day at hour 14.

sorry, to clarify:

~/Library/LaunchAgents - run job as user for a particular user

/Library/LaunchAgents - run job as user for every user

/Library/LaunchDaemons - run job as root for every user

keep in mind that LaunchDaemons need to be background only - if you need to launch a GUI app as root (a funky scenario that you probably shouldn't be doing anyway) you'll need to be creative.

lol - well, it sounds a little 'miffed', and you've forgotten or glossed over a few useful points (e.g., the fact that they don't have to use launchctl to load the plist except when they are editing it). If you'd like I'll do a quick collab on it for form and content, and toss in some launchd templates I have lying around as well. let me know. :-)