X

mac.column.ted: Customizing System-level Startup

mac.column.ted: Customizing System-level Startup

CNET staff
8 min read

by Ted Landau

Show of hands...how many of you have heard of Startup Items in Mac OS X? No, I am not talking about the list of items (that used to be called Login Items) that appear in the Startup Items tab in the Accounts System Preferences pane. I am talking about the "true" Startup Items -- the ones that reside in the StartupItems folder in the /System/Library directory. These items -- part of the standard installation of Mac OS X -- run each time you restart your computer, even before you log in to your account. They are responsible for launching an assortment of critical Mac OS X services, especially those related to networking and sharing. An additional StartupItems folder may be found in the /Library directory. This one is available to third-party software (or to you, should you care to create your own startup item) to similarly initiate an action that will run at startup regardless of which user logs in.

This article is not about these Startup Items. I only mention them to tell you that, starting with Panther, Apple has moved to abandon these Items. That's right, Apple will likely no longer be using Startup Items in the next version of Mac OS X. Their replacement is already in place and in limited use in Panther. They are called Bootstrap Daemons. This column, which is admittedly a bit more technical than my previous columns, provides an overview of what these daemons are and how you can easily create one yourself.

 

Bootstrap daemons Bootstrap Daemons get launched at two different points in the startup sequence:

  • The first time is relatively early in the startup sequence, around the same time that Startup Items are run. The daemons that are loaded at this point are stored in the following Unix directory: /etc/mach_init.d. The daemons stored here include ones for starting up Unix's configd and lookupd services. (If you don't know what these are, don't worry; you don't need to know to follow along here.)

  • A second set of daemons are run when the loginwindow application is run. That is, they are run just after you enter your name and password to log in to your account. (If you are set to automatically log in, these daemons run at the same post-login point even though you never manually enter your name and password.) These secondary daemons can be found at this location: /etc/mach_init_per_user.d. In a default Panther system, the only daemon in the this directory is MirrorAgent.plist (which is used to manage the local copy of an iDisk, if present).

The items in the mach_init.d directory normally load only when you restart your Mac. Thus, if you simply log out and log back in (or another user logs in), these items won?t be restarted. The items in mach_init_per_user.d, however, are loaded whenever any user logs in, even if the user simply logs out and back in again. These secondary daemons are thus ideal for events that need to be launched with each login (which is especially useful in Panther where Fast User Switching allows multiple users to be logged in at the same time). This similarly means that, unlike the Startup Items listed in your Accounts pane, a single daemon affects all user accounts, eliminating the need to create a separate duplicate daemon (or Startup Item) for each user.

Enough with the abstract descriptions. To show how all of this works, let's create a bootstrap daemon ourselves. The one we create does something similar to what a personal Startup Item (in your Accounts pane) would do: launch an application. In this example, we will launch the Preview application. Bootstrap daemon files are .plist (property list) files. Although they can be opened and edited in any text editor, I find it more convenient to work with them via the Property List Editor application that is included as part of Apple's Xcode Tools (Developer) software (see the Figure 1). If you open any existing bootstrap daemon, it will likely contain three properties:
ServiceName. The value of this key is the name of the bootstrap service. The name typically follows the name format used by preferences files in your ~/Library/Preferences folder. For example, the ServiceName value for the WindowServer.plist daemon is com.apple.windowserver. For a daemon you create yourself, the name can usually be whatever you want (in fact, you can leave out this property altogether). Command. The value of this key is the absolute pathway to the executable file that runs when the daemon loads. For Apple's pre-installed daemons, most of the executables are either in Unix directories (for example, the configd and lookupd executables are in /usr/bin) or in /System/Library/Frameworks/ApplicationServices.framework (this is where windowserver is located). For the daemon we create here, it will be where the Preview executable is located. OnDemand. This is an optional key. By default, OnDemand is set to on. However, if this key is added and set to a Boolean value of False (or No), the on-demand feature of the daemon is disabled. OnDemand refers to a major advantage of Bootstrap Daemons over the older Startup Items: Daemons can launch on demand -- that is, a loaded process can "sleep" when not needed, significantly reducing its effect on system load and thus reducing performance slow-downs.
To create a bootstrap daemon that will launch the Preview application at each login, do the following:
  1. Launch Property List Editor and click the New Root button.
  2. Click the disclosure triangle next to the newly create Root property.
  3. Click the New Child button.
  4. Change the name "New Item" to "Command". Leave the Class as "String".
  5. For the Value, enter the following: "/Applications/Preview.app/Contents/MacOS/Preview".
  6. Save the file to your Desktop. The name of the file, aside from the .plist extension, is not critical. I chose "launchpreview.plist".
  7. Choose Go to Folder from the Finder's Go menu. Type "/etc/mach_init_per_user.d" and press Return.
  8. Drag the launchpreview.plist file to the folder window. When the Authentication dialog appears, enter your password.
The next time you or any other user on your Mac logs in, Preview will launch. It will launch significantly earlier in the sequence of events than if you had added Preview to your Startup Items list. For example, with the Bootstrap Daemon, Preview is already open even before the Dock appears. Note: To get the daemon to work, the Command property has to point to the executable file inside the Preview.app package -- not the Preview.app itself. This is different than if you had selected Preview to be in your Startup Items list; in the latter case, you point to the Preview.app item itself. Of course, just opening an application is only the beginning of what you can do with bootstrap daemons. They can also reference documents, including Terminal shell scripts and AppleScripts, which can thus be used to initiate a series of events -- similar to how most of the System-level Bootstrap Daemons work.

Figure 1: The contents of two bootstrap daemon files: (a) configd.plist and (b) launchpreview.plist (which I created).
System-level loginwindow.plist. As is often the case in Mac OS X, there is more than one way to accomplish a goal. In this case, if you prefer not to work with bootstrap daemons, you can get an application to launch at login for all users by adding the application to the loginwindow.plist file in the /Library/Preferences folder (creating this folder and/or file, if they do not already exist). Glossing over the specific steps involved, this file follows the same format as the loginwindow.plist file in the Library/Preferences folder in your Home directory (which is where the items in your personal Startup Items list are stored). In particular, check out the numerical children of the AutoLaunchedApplicationDictionary property for the file to see how to set up your own file. You can leave off the alias property in the items you create; it will still work.

Figure 2: A loginwindow.plist file that, when placed in /Library/Preferences, will launch Preview at login for all users.
Bottom line. Each method (bootstrap daemons and loginwindow.plist) has its own pluses and minuses. I like that each bootstrap daemon is a separate file and that its action occurs prior to the desktop and Dock loading. However, your personal daemons are stored in Unix directories and could get wiped out in an upgrade to Mac OS X -- so maintain backups! In either case, if your Mac has multiple users, and you've been wishing for a simple way to customize the login for all accounts, you wish has now been granted.

 

Tip of the month: Deciding on digital camera batteries

I recently bought a new digital (still picture) camera. In researching which camera to purchase, one issue that frequently came up was the type of battery. Some cameras use standard AA batteries while others use a proprietary rechargeable battery. The typical advice is, all other things being equal (which they never are, of course), to give a preference to cameras that use AA batteries. The logic is that these batteries are cheaper than the propriety batteries and more readily available. In a pinch, should the batteries you are using run out of power, you can buy AA batteries virtually anywhere.

In my opinion, this advice is wrong. I prefer the proprietary batteries. Here's why: I looked at a Canon A80 which is a very small camera that runs on 4 AA batteries. These batteries add significant weight to the camera, already one disadvantage. Second, standard AA batteries don't last for more than a few snapshots (not to mention that it can be expensive to have to keep purchasing new batteries). So the first thing you should do after getting this camera is purchase 8 rechargeable AA batteries and a recharger. Four batteries go in the camera and 4 remain as a quick replacement (adding still more weight to lug around). The cost of these batteries and charger is not trivial. Figure at least $50 (and possibly more, especially if you want the batteries that recharge in 15 minutes). In contrast, I looked at an Olympus camera that uses a proprietary LiOn battery. The battery is much smaller and lighter than 4 AA batteries. The camera comes standard with an external charger, so you don't need to purchase one separately. Finally, the cost of a second back-up battery is less than what I would have spent on 8 rechargeable AA batteries and a recharger. The one remaining potential advantage of the AA batteries is their availability. However, my previous digital camera ran on AA batteries and, using rechargeables, I never once found myself in a position where I needed to run out and get batteries at a drug store. It could happen, but I wouldn't let this affect my decision as to which camera to get. Note: This article is adapted from my just-released new book: Ted Landau's Mac OS X Help Line (Peachpit, 2004). For more details on the material in this article -- plus the scoop on hundreds of other Mac OS X troubleshooting-related topics -- get the book. This is the latest in a series of monthly mac.column.ted articles by Ted Landau. To see a list of previous columns, click here. To send comments regarding this column directly to Ted, click here.

Resources

  • More from Mac Musings