Section 11.8. Daemon Management

11.8. Daemon Management

Panther relies on the services of a large number of system daemons for its operation, and every network service you enable adds to the count of potential background processes. While it would be easiest to simply have all the daemons launch at startup, it's much more efficient to do this for just the handful that require it and launch the other daemons only as needed. To coordinate this complex task, Tiger uses three mechanisms: bootstrap daemons , StartupItems , and launchd .

11.8.1. Bootstrap Daemons

Introduced with Panther, the register_mach_bootstrap_servers tool, provides a way to have system daemons launch on demand (that is, not until they receive their first service request). In fact, this method will eventually take the place of the StartupItems (see the following section) as Mac OS X evolves in future releases.

This tool assembles a list of daemons by reading each file in /etc/mach_init.d/ (for system daemons to be run as root) and /etc/mach_init_per_user.d/ (for user daemons to be run under normal user accounts). It then registers each daemon in the list and the service it provides with the mach_init daemon, itself launched by the Mach kernel early in the startup.

Once a daemon is registered, mach_init waits for requests from other processes for the services the daemon provides, launching (or relaunching) the daemon only when it detects a request. Such daemons, available to the system so early in the startup process, are known as bootstrap daemons . For now, only about a dozen system daemons are handled this way, none of which are network services.

11.8.2. StartupItems

The second mechanism, though now legacy, is still responsible for starting many system and network daemons. During system startup, the SystemStarter application scans and runs special scripts kept in /Library/StartupItems/ . If you've installed a daemon yourself and wish to have it launch at startup and be owned by the root user (so that it is running when the first user logs in, and continues to run until the machine is shut down or it's explicitly killed ), add another item to this collection of startup items or copy or modify an existing one, if applicable . (More startup scripts are in /System/Library/StartupItems/ , but, like everything else in the /System/ folder, are not meant to be messed with.)

Each object under StartupItems is a folder named after its function. Inside it are two important files: a parameter list of options in StartupParameters. plist and the script itself, which must have the same name as the folder.

Example 11-1 shows a simplified version of the contents of the Apache startup item ( /System/Library/StartupItems/Apache /Apache) .

Example 11-1. The Apache startup item, simplified
   [1]   #!/bin/sh     ##     # Apache HTTP Server     ##   [2]   /etc/rc.common   [4]   StartService ( )     {         if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then             echo "Starting Apache web server"             if [ ! -e /etc/httpd/httpd.conf ] ; then                     cp -p /etc/httpd/httpd.conf.default /etc/httpd/httpd.conf             fi             apachectl start         fi     }   [5]   StopService ( )     {         echo "Stopping Apache web server"         apachectl stop     }   [6]   RestartService ( )     {         if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then             echo "Restarting Apache web server"             apachectl restart         else             StopService         fi     }   [3]   RunService "" 

Here's what it does, in order:

  1. The "shebang" line ( #!/bin/sh ) marks this file as a shell script.

  2. It uses the shell's dot command (.) to execute the shell script at /etc/rc.common . This script sets up many environment variables useful to startup scripts.

  3. The script's next command actually comes with this last line, which calls one of the three functions [*] found in the preceding lines. The RunService command calls a function (defined by rc.common ) that tells the script which of its own three functions to call next, based on the argument provided with this script's execution command. Possible arguments are start , stop , or restart .

    [*] A function is a chunk of code, defined here within curly braces, that works like a script-within-a-script. Functions are read and stored in memory as the script is executed, but aren't themselves executed unless called by name elsewhere in the same script or from within a different script.

  4. If the argument is start , the script then knows to execute its StartService( ) function, which determines what to do next based on what's in the WEBSERVER environment variable (set by rc.common , after it reads the /etc/hostconfig file). If its value is -YES- , it dumps a status message to the console (which passes it along to the startup screen) and executes the apachectl start command.

  5. If the argument is stop , the script executes its StopService ( ) function, which dumps a status message and stops Apache.

  6. If the argument is restart , the script executes its RestartService ( ) function. If WEBSERVER 's value is -YES- , a status message displays, and Postfix is told to re-read its configuration. Otherwise, the StopService function is executed.

11.8.2.1. Manually running StartupItems

Much like their counterparts, the /etc/rc.init scripts found on Linux and BSD systems, StartupItems can also be run on the command line. When available, it's generally a better idea to use a daemon's StartupItems rather than invoke it directly (i.e., by using /System/Library/StartupItems/Apache/Apache instead of directly calling /usr/sbin/apachectl ) because the script is "safer"; it ensures that the machine's software and network environment is set up correctly for the daemon's use.

Typically, you must run StartupItems as root (or under the auspices of the sudo command), and, as with the Postfix StartupItem , provide one of three standard arguments:



start

Launch the service this StartupItem represents. It usually fails if it's already running.



stop

Kill this service.



restart

Equivalent to stop -ing and then start -ing the service; often it actually sends a HUP (hang-up) signal to the service's process. This causes it to reread its configuration files and act appropriately, allowing it to reconfigure itself without suffering any downtime.

11.8.2.2. The /etc/hostconfig file

Many StartupItems (like the one for Apache) must make a choice about whether they're supposed to perform their stated function. If you don't want your machine to run as a web server, for example, then you won't want the Apache startup script to launch the httpd daemon. You could modify or remove the /System/Library/StartupItems/Apache folder, but that's a messy solution that would probably lead to confusion if you (or, worse , another administrator on the machine) want to activate Apache later on.

A better solution, and the one that Mac OS X intends you to use, involves modifying the /etc/hostconfig file. This file, which is nothing more than a newline-separated list of key/value pairs (as well as a few comments), is loaded by /etc/rc.common , a shell script which itself is run as an initial step by most startup scripts. This means that all the variables it sets become accessible to scripts that load rc.common , such as the Apache startup item. Thus, if you simply set hostconfig 's WEBSERVER key to -NO- , the Apache startup script deduces that you don't want web services activated on startup and quietly exits rather than launch the httpd daemon. (This is, in fact, exactly what happens when you deactivate the Sharing preference pane's Personal Web Sharing checkbox. Many other System Preferences controls can also modify lines in /etc/hostconfig .

11.8.2.3. StartupParameters.plist

The StartupParameters .plist file (an example of a property list XML file, detailed in Chapter 13) can contain the following keys:



Description

A brief description of this startup item's function, such as "Apache web server."



Provides

A list of keywords that name the services this startup item provides, when run.



Requires

A list of keywords that name the services that must already be running before this startup item can be launched.



Uses

A list of keywords that names the services this startup item could use, but doesn't absolutely require.



Messages

A dictionary of status messages that get sent to the console (and the startup screen, if it's visible) when the startup item starts or stops.



OrderPreference

For cases in which the Requires and Uses keys specify the same startup order for multiple items, this key specifies in a relative way when the startup item should launch. Possible values are First , Early , None , Late , and Last .

The SystemStarter program determines the order in which to run all the system's startup items by scanning their StartupParameters.plist files and comparing the values of their Provides , Requires , Uses , and OrderPreference keys. It then determines which items will provide other items' Required service; those run first, so that later items' prerequisites will be met.

11.8.3. launchd

Mac OS X Tiger introduces the latest and greatest startup scheme, launchd . It has launch-on-demand capabilities and also supports on-demand launching via Mach ports (as does the mach_init.d scheme). launchd also offers the ability to launch on demand based on file system and Unix domain socket events. The property list ( .plist ) files for system-installed daemons are in /System/Library/LaunchDaemons . Locally-installed daemons can be installed into /Library/LaunchDaemons . Table 11-1 lists and describes the system-installed daemons, most of which have counterparts in Linux and Unix systems.

You can control launch daemons with the launchctl utility. For example, to enable and load a daemon that's disabled (there will be a Disabled key in its property list file), use launchctl load -w followed by the path to the property list. For example, the following command would be enabled and start the telnet server:

 # launchctl load -w /System/Library/LaunchDaemons/telnet.plist 

You can stop and disable this daemon with unload -w :

 # launchctl unload -w /System/Library/LaunchDaemons/telnet.plist 

For more information, see launchctl in Chapter 2, or the launchctl manpage .

Table 11-1. Default Mac OS X launch daemons

Property List File

Description

Enabled by default?

bootps.plist

Starts the DHCP/BOOTP daemon.

No

com.apple.atrun.plist

Launches the atrun daemon.

Yes

com.apple.KernelEventAgent.plist

Runs the kernel event agent, which responds to low-level kernel events (such as disk and network events).

Yes

com.apple.mDNSResponder.plist

Starts the Multicast DNS responder , needed by Bonjour.

Yes

com.apple.nibindd.plist

Launches the NetInfo binder daemon.

Yes

com.apple.periodic-daily.plist

Runs the daily periodic job.

Yes

com.apple.periodic-monthly.plist

Runs the monthly periodic job.

Yes

com.apple.periodic-weekly.plist

Runs the weekly periodic job.

Yes

com.apple.portmap.plist

Starts the portmapper .

Yes

com.apple.syslogd.plist

Launches the system log daemon.

Yes

com.apple.xgridagentd.plist

Runs the Xgrid agent.

No

com.apple.xgridcontrollerd.plist

Runs the Xgrid controller.

No

com.vix.cron.plist

Starts the cron daemon.

Yes

eppc.plist

Runs the Apple Events server.

No

exec .plist

Starts rexecd , the remote execution server.

No

finger.plist

Launches the finger daemon.

No

ftp.plist

Starts the FTP server.

No

login.plist

Starts the remote login ( rlogin ) daemon.

No

nmbd.plist

Launches Samba's nmbd daemon.

No

ntalk.plist

Starts the ntalk daemon.

No

org.isc.named.plist

Runs named .

No

org.postfix.master.plist

Launches the postfix master process.

Yes

org.xinetd.xinetd.plist

Starts the Internet superserver ( xinetd ) (see xinetd below).

Yes

printer.plist

Starts the CUPS lpd server.

No

shell.plist

Starts the remote shell daemon ( rshd ).

No

smbd.plist

Launches Samba's smbd daemon.

No

ssh.plist

Starts the SSH server.

No

swat.plist

Runs the Samba Web Administration Tool.

No

telnet.plist

Launches the telnet server.

No

tftp.plist

Starts the Trivial FTP server daemon.

No


11.8.4. xinetd

xinetd , the extended Internet services daemon, is responsible for launching several of Mac OS X's Internet and other IP-based daemons, including sshd (for secure shell services), ftpd (for FTP services), and smbd (for Windows filesharing and printing services). As you can see by looking at the IPServices startup script, xinetd itself is actually one of the daemons launched by SystemStarter .

Also called a super-server , xinetd launches daemons on-demand, much like mach_init . Super-serversincluding xinetd or its simpler predecessor, inetd-- are found on most other Unix-like platforms. xinetd determines which daemons it's responsible for by reading the files, each named for a service, in /etc/xinetd.d/ . Each file defines a service and series of attributes, including disable , which defines whether the service is disabled or not, and server , which specifies the daemon to launch when that service is enabled and requested .

Enabling a xinetd service typically means setting that service's disable attribute to no and sending xinetd a kill -HUP signal so it will reload its configuration files. This can of course be done manually with a text editor, but two easier methods exist that make that rarely necessary. First, for the following items the Sharing preference pane does all you need: Windows Sharing, Remote Login, FTP Access, and Remote Apple Events, since they are all controlled by xinetd .

For any other items in /etc/xinetd.d/ , you can use the service command, as shown previously in the telnet section. To stop or start a service, the command must be run as root and takes two arguments: the service name and an action, either start or stop . To list all xinetd -controlled items, run service --list as any user.



MAC OS X Tiger in a Nutshell
Mac OS X Tiger in a Nutshell: A Desktop Quick Reference (In a Nutshell (OReilly))
ISBN: 0596009437
EAN: 2147483647
Year: 2003
Pages: 130

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net