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).
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.
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.
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.
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.
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.
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.
Only the system superuser (UID 0) can execute the control and query commands (except active and depend).
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. |
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);
Besides writing control/query commands programmatically, you can use the slmctl utility to send SLM commands (via the command line or typed interactively).
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. |