QNX Process Launch and Monitor Service (QPLMS) overview

QPLMS manages and optimizes process execution by launching dependency-driven components — often in parallel — using an action queue and worker threads to support both automated and user-triggered tasks.

Functional overview

QPLMS is a safety-certified process launcher that performs the following functions:

  • Starts and stops processes according to configurable application properties
  • Resolves interdependencies between components according to a Directed Acyclic Graph (DAG)
  • Launches process on control conditions
  • Supports multi-stage system startup
  • Monitors processes (watchdog and death monitoring)
  • Recovers crashed processes by restarting the process or notifying an external health system monitor
  • Notifies external system health monitor about process states

To avoid the need to run multiple monitors on a system, QPLMS includes smart watchdog and process death capturing features.

QPLMS components

QPLMS is comprised of three main components:

  • PLMS binary (plms) - manages and optimizes process execution by launching dependency-driven components using an action queue and worker threads to support both automated and user-triggered tasks.
  • PLMS library (libplms) - provides interfaces for client applications to communicate with PLMS.
  • PLMS debug utility (plmsctrl) - a debugging utility that uses libplms to communicate with PLMS to send and receive commands and statuses.

Initialization sequence

PLMS must be launched with a configuration file specified and may be given further optional flags. The flags are evaluated before the configuration file is handled.

PLMS parses the configuration file for correctness and creates components that correspond to the descriptions in the configuration file. The created components dependencies are analyzed, and when the dependencies are resolved, corresponding directed acyclic graph (DAG) entries are created. All components (or only a specific subset of components) can be started from the command line by passing specific arguments.

PLMS creates a resource manager, action queue, controller, and worker threads according to its configuration. Then PLMS creates start actions for the components, starts the necessary dependencies, and enqueues actions in the action queue.

Interfaces

PLMS provides three types of external interfaces:

  • Command line interface - a command line interface to configure the plms instance.
  • Configuration file - a file that defines the components plms will use to handle the managed processes.
  • Control interface - a control interface through a client library so that external processes can interact with plms during plms runtime.

Component states

PLMS components can have the following states:

  • Starting - a liminal (i.e., an in-between) state where a component begins executing its start_sequence tasks.
  • Started - when a component’s start_sequence task_list is successfully completed, then the component is considered started.
  • Idle - initially, all components are in the idle state. A component can be in the idle state if it has been asked to stop with a stop reason of none.
  • Stopping - a liminal state where the component is terminated by executing stop_sequence tasks.
  • Session stopped - indicates that the component is stopped because its dependency components are stopped.
  • Fault - indicates the component has failed and cannot be recovered.
  • Defined Safe State (DSS) - a defined safe state that restarts the system by calling sysmgr_reboot().

For detailed information about PLMS component states, refer to: PLMS component states.

Dynamic memory usage

PLMS pre-allocates memory required for its operation using a fixed size allocator, and queues the memory from the allocator.

PLMS uses dynamic memory in the following cases:

  • Whenever a new configuration file is added to PLMS via the startup specification, or via the API, PLMS uses dynamic memory to parse the configuration file and update the existing data structure. If PLMS is unable to allocate the memory during parsing, PLMS rejects the configuration file and continue execution.
  • When a new client connects to the PLMS resmgr, PLMS allocates an OCB for the client connection. If OCB allocation fails, then PLMS rejects the client open call.

Shared memory

PLMS uses shared memory for watchdog monitoring functionality. The shared memory design is chosen to mimic clients writing to a hardware watchdog, as this separates the client and PLMS execution. Memory is shared as anonymous shared memory via the PLMS library for security isolation.

Processes and threads

PLMS is a multithreaded application which can be used by multiple clients.

For more information about PLMS threading, refer to: Threading.

Page updated: