Page Comparison

The sipXsupervisor manages all other sipXecs processes.  To give the supervisor the information about a process that it needs to manage the process correctly, the installer for the process must install a process definition into the directory {{$\{prefix\}/share/sipXecs/process.d}}, whose file name is {{_name_-process.xml}} (where _name_ is unique to the process).

The XML schema for the process definition is at {{[sipXsupervisor/meta/sipXecs-process.xsd.in|http://sipxecs.sipfoundry.org/rep/sipXecs/main/sipXsupervisor/meta/sipXecs-process.xsd.in]}}. This page explains the elements and attributes defined by that schema, and to use them to ensure proper management of any sipXecs component.

The top level element of the process definition document is *{{sipXecs-process}}*.  The contents of {{sipXecs-process}} are:

Exactly one of each of:
* *{{name}}*: the name of the process - this is used to identify this process in control operations and alarms.
* *{{version}}*: the version number of the process (see [#Versions])
* *{{commands}}*: commands used to control the process (see [#Commands])
* *{{status}}*: status files for the process (see [#Status])
and optionally one:
* *{{resources}}*: list of resources used by the process (see [#Resources])

{note}
The process definition file is read-only - it is only read by the sipXsupervisor, and is never modified by anything (except when being replaced by the new version when the component is upgraded).
{note}

h1. Process Management State Machine

In order to understand how the various elements of the process definition are used, it helps to understand the sipXsupervisor process management state machine (this diagram is slightly simplified from the actual state machine for clarity). {color:darkgreen}The dark green states and paths are the normal successful sequence of states and events{color}.  The Enabled and Disabled states are the permanent states of a process, established by start and stop commands from sipXconfig; the start and stop commands are persistent - each sets the desired state of the process, and that desired state is saved by the supervisor (there is also a restart command which causes the process to stop and restart without ever changing the persistent desired state).

{graphviz}
digraph {

node [shape=oval];

subgraph cluster_states {
style=invis;
node  [shape=rectangle];

ShutDown [label="Enabled / Shut Down"];
Disabled;
}

subgraph {
node [shape=oval, color=darkgreen, fontcolor=darkgreen];
edge [color=darkgreen, fontcolor=darkgreen];


Disabled -> ConfigurationMismatch [label="start command"];

ConfigurationMismatch [label="Compare Process and Config Versions", URL="#Versions#SupervisorProcessDefinitions-Versions"];
ResourceRequired      [label="Check Resources"];
Testing               [label="Run Configuration Test"];
Starting;
Running;
ShuttingDown          [label="Shutting Down"];

ShutDown -> ConfigurationMismatch [label="system start"];
ConfigurationMismatch -> ResourceRequired [label="versions matched"];
ResourceRequired -> Testing  [label="resources ready"];
Testing -> Starting          [label="passed"];
Starting -> Running          [label="started"];

Running -> ShuttingDown      [label="shutdown command"];
ShuttingDown -> ShutDown     [label="stopped"];

}

subgraph errors {

node [color=red, fontcolor=red];
edge [color=red, fontcolor=red];

Failed;

ConfigTestFailed      [label="Invalid Configuration"];
Testing -> ConfigTestFailed  [label="failed"];
Starting -> Failed           [label="failed"];
Running -> Failed            [label="failed"];
}

ConfigurationMismatch -> ConfigurationMismatch [label="version set"];
ResourceRequired -> ResourceRequired  [label="configuration change"];
ConfigTestFailed -> Testing  [label="configuration change"];
Failed -> ConfigurationMismatch [label="retry timeout"];

Running -> ConfigurationMismatch [label="restart command"];
Stopping;
Running -> Stopping          [label="stop command"];
Stopping -> Disabled         [label="stopped"];


}
{graphviz}

h2. Versions

The first check that the supervisor does before starting a process is that the version number in the process definition matches the version of the configuration data; this ensures that sipXconfig has a chance to update configuration data to the correct format and content following an upgrade before the process is started.  The contents of the sipXecs-process/version element are compared with a value written by sipXconfig through an XML-RPC interface that establishes the version number for any configuration data.  The values are compared as strings, and must match exactly.

h2. Commands

h3. Configuration Test

h3. Start

h3. Stop

h2. Status

h3. Log files

h3. Process Id files

h2. Resources