Running the SLM service

Synopsis:

slm [-a | -C | -D debug_mode | -k | -n subsystem_path | -p priority | -P search_path | -r recovery_mode | -R recovery_times | -s comp_name | -t polling_interval | -T total_wait | -v | -V | -x comp_name] config_file

Options:

-a

Adopt running daemon processes. Use this option to integrate SLM with an existing system where some server processes may already be running. If you place component entries for all relevant system processes in the configuration file, SLM will adopt these processes at startup as if it had launched them itself (and can thus control the processes via the command interface or restart them automatically if they terminate abnormally).

-C
In case of error, let slm continue to work rather than bail out.
-D

Specify when to use the <SLM:debug> argument list (instead of the normal <SLM:args> list). One of: cmd (default), startup, or always. With cmd, the debug list is used only when the module is started with the -d option. With startup, all components launched at startup (see the -s option) will initially use the debug list, but will then honor the -d option of subsequent restarts. With always, the debug list is always used.

-k

Control whether PATHSPACE and DAEMON_DIED system events should be used to kick the normally poll-driven waitfor and stop handling. Since these events are also used by other processing, each event trigger may require an additional amount of unrelated activity, but generally this is faster than the default polling periods in detecting process state changes. Using these system events is enabled by default; specify -k if you don't want to use them.

-n
Set the access point (default is /dev/slm) for client applications to write control and query commands.
-p
Set the priority of the SLM server threads (default is 30).
-P

Set the search path for executables (default is $PATH). When launching a process, SLM looks in the search path to find the executable if the corresponding command tag doesn't contain a full path.

-r

Set the recovery mode for components monitored by SLM. One of: none (default), stop, or replace. The action specified with the -r option is performed when a component terminates abnormally if that component doesn't override this setting in its repair tag.

-R
Set the maximum number of times to attempt recovery (default is 2 times per minute).
-s
Name a component or module to launch at startup. For convenience, you can use the built-in modules "all" and "none" (default is "all").
-t
Set the polling interval in milliseconds for the wait property. Default is 100.
-T
Set the total wait time in milliseconds. Default is 50000.
-v
Increase output verbosity (messages are written to sloginfo). The -v option is cumulative; each additional v adds a level of verbosity, up to 7 levels.
-V
Log output messages to console (as well as sloginfo).
-x
Name a component or module to terminate at shutdown. For convenience, you can use the built-in modules "all" and "none" (default is "all").

Description:

SLM is started from startup.sh, which runs during the boot sequence. In the SLM command line inside startup.sh, you must specify a configuration file, but all the other parameters are optional.

Control and query commands

Client applications can control SLM by writing commands to the /dev/slm interface.

Control commands can start, stop, restart, or replace a specified module or component. When you start a component, SLM will start any dependencies (that aren't already running) and wait for them as required. When you stop a component, SLM first stops any dependents on the component. Restarting is a sequential composition of stop and start operations and is typically applied to set a specific high-level module state. Replacing will stop and relaunch a component and then restart any currently active components that had a dependency on that component. This is typically applied to update a low-level component process.

Query commands can list the dependencies (depend), running components (active), or components that terminated abnormally (dead). Command lines consist of the command, any options, and a module or component name, if appropriate.
Note:

Only the system superuser (UID 0) can execute the control and query commands (except active and depend).

The following table summarizes the control and query commands:
Command Options Description
active -v List the active (running) components.
dead -v -w List the dead (faulted) components.
depend -s -u -v List dependencies or dependents for the specified component.
start -d -v -x Start the specified component.
stop -s -v -x Stop the specified component.
restart -d -s -v -x Stop then start the specified component.
replace -d -s -v -x Update the specified component.
The following table describes all the options:
Option Description
-d Debug mode: start components with their debug argument list.
-s Stateless: ignore any stateless dependencies when stopping components.
-u Used by: list components that depend on the specified component.
-v Verbose: give details of each action performed when responding to a command.
-w Wait: block until a process terminates abnormally.
-x Explain: list the required actions but don't perform them.

Command example

Following execution of a command written to /dev/slm, the results are available to be read from the same file descriptor. Here's a simple example (with no error handling):
int    slm;
char   text[128];

slm = open("/dev/slm", O_RDWR);
write(slm, "start -v all", 12);
while (read(slm, text, sizeof(text)) > 0)
printf("%s\n", text);
close(slm);

Issuing commands via the slmctl utility

Besides writing control/query commands programmatically, you can use the slmctl utility to send SLM commands (via the command line or typed interactively).

The utility displays the results of each action in a line describing the operation on the specified component or module as follows:
Utility output Meaning
START component pid|error Component was started.
start component Component already active (no errors).
WAIT component error Waiting for component.
wait component Component already active (no errors).
STOP component error Component stopped.
stop component Component already inactive.
BEGIN module Encapsulation of multiple components.
END module error Reported only via sloginfo, not slmctl.