System Launch and Monitor (SLM)

The SLM service automates process management.


SLM is started early in the boot sequence to launch complex applications consisting of many processes that must be started in a certain order.

SLM is controlled by a configuration file that specifies the processes to run and their properties, especially any interprocess dependencies. For example, suppose a multimedia application needs the services of the audio subsystem and the database server, which in turn needs the services of PPS. When SLM learns of these one-way dependencies when reading the configuration file, the service internally constructs a directed acyclic graph (DAG) representing the workflow of the underlying processes. This DAG is sorted to produce a partial ordering for scheduling the processes so that all control-flow dependencies are respected. In this example, SLM would first check that PPS is running before starting the database server and then check that the database server is up before starting the multimedia app.

SLM configuration file

SLM uses an XML configuration file to determine the appropriate order for scheduling processes. The configuration file lists all the processes for SLM to manage, any dependencies between the processes, the commands for launching the processes, and other properties.

Configuration file structure

The root XML element of the configuration file is the system tag. All element names start with SLM:, so the root element (and the outline of the file) looks like this:

    -- component and module descriptions --


A process managed by SLM is represented by a component. You must provide a component name (usually based on the process name) that will be used within the configuration file when specifying interprocess dependencies or membership in a group of components.

All component tags are listed in the root element and contain other tags that describe the properties of individual components. The component tag syntax is as follows:
<SLM:component name="mcd">
    -- component properties --

The following table describes the component tags:

Tag Attribute Value(s) Description
args   command_args The list of command-line arguments to provide the binary executable.
cd   dir_name

The directory to switch into when launching the process; this directory becomes the process's working directory ($CWD).

command launch [ bg[,nohup] ] Controls process creation.
  pathname The full path of the binary executable (e.g., /usr/bin/mcd).
debug   command_args

An alternative list of command-line arguments to provide the binary executable when SLM is run in debug mode. This list might contain options (such as -v to increase verbosity).

depend state [ session | stateless ]

A component may need other services to be active before the component can run. Any prerequisites must be expressed as dependencies.

There are two forms of dependency: session (stateful) and stateless. With session dependency (the default), a client/server relationship is assumed; the server stores state information on all its clients. In this model, if the server must be stopped or restarted, then all its clients must be stopped.

With stateless dependency, the server doesn't maintain any client information, so it's not necessary to restart clients if the server is restarted.

  component_name Name of the prerequisite component. A component can have zero, one, or many dependencies.
Note: You must define a separate tag for each dependency.

SLM won't start a component until all the prerequisites are running.

priority   priority_policy An alphanumeric value indicating the priority level and scheduling policy to assign the process (e.g., 10r).
repair   [ default | none | stop | replace ] Specifies the action to take if the component terminates abnormally:
  • default—tells SLM to perform the action specified by the -r command-line option
  • none—SLM takes no recovery action
  • stop—SLM stops any other components that depend on the component that failed
  • replace—SLM restarts the failed component
stderr iomode [ w[+] | a[+] ] The access mode: overwrite (w), read and overwrite (w+), append (a), or read and append (a+).
  filename Name of the file for redirecting standard error (stderr).
stdin iomode [ r[+] ] The access mode: read only (r) or read and write (r+).
  filename Name of the file for redirecting standard input (stdin).
stdout iomode [ w | a ] The access mode: overwrite (w) or append (a).
  filename Name of the file for redirecting standard output (stdout).
stop stop [ none | signal ]

The signal setting (the default) causes SLM to send a signal to the underlying process. The none setting disables the signaling; in this case, SLM takes no action to stop a process.

child [ self | before | after ]

For any process launched by SLM, its child processes are out of SLM's direct control. You can specify the shutdown of these child processes as relative to when the SLM-controlled parent process is terminated. The settings are: self (the default), before, and after.

Contains the signal number to send the process to stop it. By default, SIGTERM is sent, but you can change this to any signal. If repeated failed attempts to stop the process fail, SIGKILL is sent.
Note: This tag value isn't needed when the stop attribute is set to none.
user   uid:gid The user ID and group ID to assign to the underlying process. The two strings are separated by a colon (e.g., jgarvey:techies).
waitfor wait [ none | delay | pathname | exits | blocks ]
Once a component has been launched, SLM can wait for that component to set itself up before starting any dependent components. Values:
  • none (the default)—causes SLM to start other components immediately
  • delay—SLM pauses for the specified number of milliseconds
  • pathname—SLM probes for the appearance of the specified pathname
  • exits—SLM waits for the process to finish
  • blocks—SLM waits for a specified thread in the process to reach the RECV-blocked state
  data Contains data specific to the specified wait condition. For example, for delay, the value could be 5000 (for a 5s delay).

Only the command property is mandatory—all processes must have a path to the binary executable. The remaining properties are optional.


You can group components into modules. The processes within a module could make up a subsystem or could be used to establish a set of system states, such as a base level of operation and various higher levels. Modules must be named so they can be internally referenced. Each module must be described in a tag, as follows:

<SLM:module name="device_monitors">
    -- module description --

To list the components within a module use the member tag. There are no attributes for member tags; the tag values refer to member components by the internal names defined in their respective component tags.


You can include multiple components in a module by using one member tag with wildcards in the component names. For example, you can write:


Modules can have dependencies on components or on other modules. Each dependency must be specified in a depend tag within the module tag.

Components and modules may be specified in any order in the XML configuration file, but SLM will raise an error if any circular dependencies are found.

Sample configuration file

Suppose you want to automate the setup of your system's IP connectivity. This would require running io-net, which creates an IP socket for network traffic, and then running ifconfig to bind an IP address to the socket. You can create a module to include two components that correspond to the two services, and then describe the dependency of ifconfig on io-net in the component entries. The XML file would then look like this:

    <SLM:component name="io-net">
        <SLM:args>-del900 -ptcpip-v4</SLM:args>
        <SLM:waitfor wait="pathname">/dev/socket</SLM:waitfor>
    <SLM:component name="ifconfig">
        <SLM:args>en0 up</SLM:args>
        <SLM:waitfor wait="exits"></SLM:waitfor>
    <SLM:module name="net-setup">