Volume Number: 25
Issue Number: 09
Column Tag: MacEnterprise

MacEnterprise: launchd for Lunch

Recipes for using launchd for systems administration

By Greg Neagle, MacEnterprise.org

A few months ago, we looked at how to run administrative scripts - how a systems administrator could run a script at startup, or a schedule, at user login, and more. There are many mechanisms to launch scripts at specific times and under specific conditions, but the one that came up over and over was launchd.

This shouldn't be surprising. Apple introduced launchd with the release of OS X 10.4 Tiger, and their stated goal was to make launchd replace most the other ways of launching processes on OS X. Specifically, launchd was designed to take over tasks from cron, xinetd, mach_init, and init, and to largely replace the StartupItem mechanism.

Recently on the MacEnterprise mailing list there was a discussion about accomplishing a certain task with a login hook. There was a reply that if one could accomplish the task using a launchd LaunchAgent, that would be preferred. Then the floodgates opened. A big discussion ensued about LaunchAgents versus login and logout hooks, launchd jobs as compared to cron jobs, and so on. It was quickly apparent that launchd was still not completely understood or trusted by many Mac OS X systems administrators. More specifically, it became clear there is still a need for concrete examples of how systems administrators can use launchd to replace other launching methods, like cron or a StartupItem, and to do things those launching mechanisms cannot. So in this column, I will present some "launchd recipes" - code snippets you can adapt to use for your own tasks.

Before we can look at some recipes, let's do a quick review of some of the ingredients we'll be working with.

A key concept is that launchd is just a mechanism to launch processes under certain conditions, and to optionally keep them running even if they unexpectedly exit. Launchd is not a scripting language. To do anything useful with launchd, you must have two ingredients:

A launchd plist. This is a configuration file that tells launchd what to launch, and under which conditions. We'll be looking at several example plists in this month's column.

The actual executable task. This can be a script, or a pre-compiled binary. This is what launchd runs for you when the conditions described in the launchd plist are met.

In most of these recipes, I leave it to you to supply the script. The focus of this column is how to get launchd to execute your script under the right conditions.

If you compare launchd to some of the more traditional methods of running tasks, you'll see the other methods support a more limited set of conditions. For example, the StartupItem mechanism can run a task only at startup. cron can run a task only at a certain time. periodic runs tasks only at certain intervals. xinetd can run a task only when a connection is attempted on a certain network port. Login items are executed when a user logs in. Launchd can run tasks based on all of these conditions, and more.

Launchd plists typically go in one of three locations: /Library/LaunchDaemons, /Library/LaunchAgents, and ~/Library/LaunchAgents. (There are two more directories containing launchd plists - /System/Library/LaunchAgents and /System/Library/LaunchDaemons, but these are reserved for use by Apple.) The launchd plists in /Library/LaunchDaemons are loaded at startup (this does not necessarily mean that the jobs themselves are run at startup, though) and the plists in the two LaunchAgents directories are loaded at user login (or other login-related contexts).

Two more things to know about launchd plists: they must be owned by root, and have permissions 0644. If launchd doesn't like the ownership or permissions of a plist, it will refuse to load it.

Now that we've reviewed the ingredients - on to the recipes!

This is the simplest recipe. We have a script we'd like to run at startup.

Create a plist in /Library/LaunchDaemons with contents similar to these:

<?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.myorg.startup.scriptname</string>
   <key>ProgramArguments</key>
   <array>
      <string>/path/to/script</string>
      <string>-argument</string>
   </array>
   <key>RunAtLoad</key>
   <true/>
</dict>
</plist>

You can name the plist anything you'd like ending in ".plist,' but the normal convention is to use the same name as the Label, so this plist would be named "org.myorg.startup.scriptname.plist". This launchd plist defines only three keys: Label, ProgramArguments, and RunAtLoad. Label defines a unique name for this launchd job. ProgramArguments contains the path to the command or script, plus any arguments, options, or switches to be passed to the command. If you wanted to remove the Apple Type Services databases at each startup, this command:

atsutil databases -remove

would become this in a launchd plist:

<key>ProgramArguments</key>
<array>
   <string>/usr/bin/atsutil</string>
   <string>databases</string>
   <string>-remove</string>
</array>

Note that this doesn't work:

<key>ProgramArguments</key>
<array>
   <string>/usr/bin/atsutil databases -remove</string>
</array>

The script or command itself and each argument or flag must be in a separate <string> element.

The RunAtLoad key simply tells launchd to run the job as soon as it loads this plist. Since a plist in /Library/LaunchDaemons is loaded at startup, the job is run at startup.

A common systems administration need is for "run-once" startup scripts - typically these do some sort of configuration and so only need to run once. Unfortunately, launchd plists provide no explicit support for this sort of thing. (The man page for launchd.plist mentions a "LaunchOnlyOnce" key - but this causes a job to be launched only once per boot.) Your options for a job that runs only once are:

Have the script delete the launchd plist after it runs. On the next boot, since the launchd plist no longer exists, the job will not be run again.

Have the script execute

 launchctl unload -w /Library/LaunchDaemons/myjobname.plist 

as the last thing it does. This adds the Disabled key to the launchd plist and sets its value to True, so the job won't load on future reboots unless you remove the Disabled key or set it to False. You must call launchctl unload as the last thing the script does, though, because a side effect of unloading the plist is that the script will be killed as well.

Alternately, you could use a tool like PlistBuddy to write the Disabled key to the plist; this would avoid the issue of killing the process at the same time. Here's a Perl snippet, stolen from /usr/libexec/configureLocalKDC:

my $rerun_plist = '/System/Library/LaunchDaemons/com.apple.configureLocalKDC.plist';
chomp (my $status = qx{/usr/libexec/PlistBuddy -c "Print :Disabled" $rerun_plist});
if ($status ne 'true') {
        system '/usr/libexec/PlistBuddy', '-c', 'Add :Disabled bool True', $rerun_plist;
}

Have the script check for something else to see if it has already run. The script will still run at every startup, but if it finds the existence of a certain file or directory, it exits without doing anything else. An example of something using this strategy is the Setup Assistant that runs when you first install OS X, or when you first startup a new Mac. If the file /var/db/.AppleSetupDone doesn't exist, the Setup Assistant runs on boot. When the Setup Assistant exits, it creates the .AppleSetupDone file, stopping the Setup Assistant from running on future boots. An advantage of this approach is that if you ever need to re-run the script or application for any reason, you can remove the flag file to do so.

Cron and periodic are two traditional ways to run jobs on repeating schedules. Periodic is typically used to run a job on a daily, weekly, or monthly schedule. Cron can run a job on virtually any schedule you can imagine - once a minute; every Friday at 3:45pm; every two hours between 8AM and 6PM, Monday through Friday, and more. Cron and periodic are still around in OS X Leopard (and work fine), but launchd can replace most of what they do.

Here's an example of a launchd plist that runs a script every day at 5:15 AM:

<?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.myorg.daily.radmind</string>
   <key>ProgramArguments</key>
   <array> 
      <string>/usr/local/radmind/run_radmind</string>
   </array>
   <key>StartCalendarInterval</key>
   <dict>  
      <key>Hour</key>
      <integer>5</integer>
      <key>Minute</key>
      <integer>15</integer>
   </dict>
</dict>
</plist>

This plist has no RunAtLoad key, since we don't want the script to run at startup. Instead, it has a StartCalendarInterval key, which describes the repeating schedule for the script. StartCalendarInterval is either a single dictionary or an array of dictionaries. Each dictionary can have any combination of the keys Hour, Minute, Day, Weekday, and Month. In this example, the job will run whenever the hour is 5 and the minute is 15. Since the keys Day, Weekday, and Month aren't specified, the job will run every day of every month. The only key that might be non-obvious is Weekday. This takes an integer from 0 to 7, and both 0 and 7 correspond to Sunday.

It's possible to replicate almost all of the scheduling possibilities that cron offers, though the launchd plist version will be much more verbose. You can specify multiple calendar intervals by setting the StartCalendarInterval value to an array of dictionaries, like this:

<key>StartCalendarInterval</key>
<array>
   <dict>
      <key>Hour</key>
      <integer>3</integer>
      <key>Minute</key>
      <integer>15</integer>
   </dict>
   <dict>
      <key>Hour</key>
      <integer>10</integer>
      <key>Minute</key>
      <integer>30</integer>
   </dict>
</array>

This StartCalendarInterval would cause the job to be run at 3:15 AM and 10:30 AM.

The other launchd key that is of interest in scheduling repeating jobs is StartInterval. The value for this key is an integer representing the number of seconds between job runs. The following example causes the job to be run every five minutes:

<key>StartInterval</key>
<integer>300</integer>

If you have a script you'd like to run at startup and also on a regular schedule - for example, a script that uploads asset information about the current machine - you can add both a StartCalendarInterval and a RunAtLoad key to the launchd plist:

<?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.myorg.assetinfoupload</string>
   <key>ProgramArguments</key>
   <array> 
      <string>/usr/local/scripts/asset_info_update</string>
   </array>
   <key>StartCalendarInterval</key>
   <dict>  
      <key>Hour</key>
      <integer>12</integer>
      <key>Minute</key>
      <integer>15</integer>
   </dict>
   <key>RunAtLoad</key>
   <true/>
</dict>
</plist>

Launchd can run a job when a file or directory changes. There are two relevant keys: WatchPaths, which takes an array of strings, each of which is a path to a file or a directory, and QueueDirectories, which also takes an array of strings, but these must point to directories only.

When using WatchPaths, any change to the path triggers the job. In the case of a file, touching the file or changing its contents will cause the launchd job to run. With directories, adding or removing files will start the job.

QueueDirectories are monitored a bit differently. If a QueueDirectory is not empty, your job will be started. If your job quits and the directory is still not empty, your job will be started again. The idea here is a script or program that is started when items appear in a directory, processes each one, and removes each item from the directory as it goes. This acts much like a mail queue or print queue. Prior to launchd, systems administrators would often implement a cron job that ran every minute or so and checked the directory to see if anything had been added. With launchd, you can just let launchd notify you if something appears in the directory.

A WatchPaths example:

<?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>Label</key>
  <string>org.myorg.sudoers-check</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/logger</string>
    <string>/etc/sudoers was changed!</string>
  </array>
  <key>WatchPaths</key>
  <array>
    <string>/etc/sudoers</string>
  </array>
</dict>
</plist>

This launchd job watches the /etc/sudoers file and writes a message to the log if it changes. If you were really interested in being notified when the sudoers file changed, you'd probably want to use a mechanism that sent email or posted data to a database or via a web CGI.

Sometimes there is a need to allow a standard user to run a command or script that only works properly when run as root. Building on Recipe 3, we can use launchd to enable this. By default, jobs run by launchd LaunchDaemons run as root. (LaunchAgents are a different matter.) If we set up launchd to run our script when a file changes, and that file is changeable by a standard user, then the user can run the script by changing the file.

This recipe requires some additional ingredients. We need a file that the user can change but not accidentally remove, since launchd's behavior is - shall we say - inconsistent if the WatchPath disappears. One way to do this is to create a directory that is readable by everyone, but writeable only by root:

mkdir /Library/Management/Triggers
sudo chown root /Library/Management/Triggers
sudo chmod 755 /Library/Management/Triggers

Within this directory, create a file to use as the trigger, but make it world-writable:

sudo touch /Library/Management/Triggers/softwareupdate
sudo chmod 666 /Library/Management/Triggers/softwareupdate

Now any user may change the softwareupdate file, but only root can remove it. Our launchd plist can now specify our trigger file as an item in the WatchPaths array:

<?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>Label</key>
  <string>org.myorg.softwareupdate</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/sbin/softwareupdate</string>
    <string>--install</string>
      <string>--all</string>
  </array>
  <key>WatchPaths</key>
  <array>
    <string>/Library/Management/Triggers/softwareupdate </string>
  </array>
</dict>
</plist>

This launchd plist watches the trigger file. When it changes, it runs:

softwareupdate --install --all

We need one more ingredient - a way for the user to easily modify the file. You could tell the user to open a Terminal window and type "touch /Library/Management/Triggers/softwareupdate", but they'd look at you like you're insane. So let's do something a little more "Mac-like". This could simply be an AppleScript applet that touches the file:

display dialog "Do you want to run Software Update and install all available updates?" buttons {"No", "Yes"} default button "Yes"
if button returned of result is "Yes" then
   do shell script "touch /Library/Management/Triggers/softwareupdate"
end if

When compiled and run the AppleScript presents the dialog in Figure 1.

Figure 1 - A GUI to trigger softwareupdate as root

If the user clicks Yes, the AppleScript touches our trigger file. launchd notices the change, and runs softwareupdate as root.

This example would need a lot more fleshing out before I'd consider deploying it to real users. Instead of directly calling softwareupdate, you'd probably want to write a script that called softwareupdate, provided progress feedback to the user, and handled the case where a restart is needed after updates are installed. The launchd job could then call that script. Still, the basic idea is there: a method to allow a non-privileged user to run a process as root.

There are at least a few more things systems administrators might want to do with launchd. Some examples:

Run a script (or an application) when any user logs in.

Run a script when the loginwindow loads.

Run a script when a volume is mounted.

I hope to have some recipes for these and more, and maybe cover some new Snow Leopard features in a future MacEnterprise column. Until then, you can find more info here:

"Getting Started with launchd" - hhttp://developer.apple.com/macosx/launchd.html

"Creating launchd daemons and agents" -

http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html

"Launchd in depth" - http://www.afp548.com/article.php?story=20050620071558293 (This one is a few years old; written when Tiger was new - but has a good example of WatchPaths and a quick introduction to launchctl.)

And of course, read the man pages for launchd, launchd.plist, and launchctl!

Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (macenterprise.org) and is a senior systems engineer at a large animation studio. Greg has been working with the Mac since 1984, and with OS X since its release. He can be reached at gregneagle@mac.com.