Components & Run Targets#

Overview#

The functionality of the Launch Manager is defined by configuration data, which spawns a directed acyclic graph (DAG) of Components and so called Run Targets. The Run Targets are virtual nodes in the DAG and represent Run States of the system. The Launch Manager is responsible for starting and stopping the processes in the correct order, based on the dependencies defined in the configuration data.

E.g. the configuration below consists of three Run Targets managing 9 components. If the user selects e.g. the Run Target “debug” the Launch Manager will start the components in the following order defined by the dependencies.

  1. flash driver & eth driver

  2. filesystem

  3. setup filesystems

  4. networking

  5. ssh

The Launch Manager (comp__lifecycle_launch_manager) implements the following interfaces,for the selection of Run Target s, starting and stopping of components and monitoring of the processes.

The ComponentConfig and RunTargetConfig structures defning such a dependency graph are described in Configuration Structure.

Ready Conditions#

When a component is started the Launch Manager will start the corresponding process and monitor its state via Ready Conditions.

Ready Conditions are essential mechanisms that determine when a component has successfully completed its startup phase and is ready to fulfill its intended role in the system. These conditions provide flexibility in defining what constitutes a “ready” state for different types of components. For SCORE applications, components can actively report their readiness through the Lifecycle Interface by signaling specific states or custom conditions. For native applications, the Launch Manager relies on external indicators such as process existence, file creation, network socket availability, or successful process termination. This dual approach ensures that both modern SCORE-aware applications and legacy native applications can participate in the dependency management system.

The configurable condition types are shown as ReadyCondition in Configuration Structure.

Interacting with processes#

The Launch Manager provides interfaces for communication with launched applications, supporting two distinct application types:

  1. SCORE Applications: Implement the full Lifecycle Interface for bidirectional communication with state reporting, liveliness indication, and conditional signaling

  2. Native Applications: Controlled exclusively via POSIX signals (SIGTERM, SIGKILL, etc.) without direct API communication

This dual approach enables the Launch Manager to manage both legacy native applications and SCORE-aware applications within the same system.

The Lifecycle Interface serves as the communication channel between applications and the Launch Manager.

SCORE applications#

For SCORE Applications: - Application state reporting (started, running, stopped) - Conditional signaling for application dependencies

The lifecycle interface is defined here: logic_arc_int__lifecycle__lifecycle_if

The following use cases are supported by the Lifecycle Interface, with different capabilities depending on the application type.

SCORE Application State Communication

SCORE applications implementing the Lifecycle Interface can communicate their internal state to the Launch Manager. The Launch Manager uses this state information for:

  • Dependency resolution for other applications

  • Recovery action decisions

  • Status reporting to external state managers via the Control interface (logic_arc_int__lifecycle__controlif)

Shutdown Signal Handling

The Launch Manager sends SIGTERM signal to SCORE applications (and any POSIX processes) to request their shutdown. The lifecycle interface sets up the necessary signal handler for an SCORE application to properly respond to shutdown requests.

Native Applications#

Native applications that do not implement the Lifecycle Interface are controlled through POSIX signals:

  • SIGTERM: Graceful shutdown request

  • SIGKILL: Forced termination (after timeout)

The Launch Manager monitors native applications through:

  • Process ID (PID) tracking

  • Exit code evaluation

  • Resource usage monitoring via OS facilities

  • Timeout-based failure detection

For native applications, the Launch Manager provides:

  • Basic lifecycle control (start/stop)

  • Simple dependency management based on process existence

  • Configurable startup/shutdown timeouts

  • Exit code-based success/failure determination

State machines#

A component maintains the following internal state machine:

Note that the state machine of the underlying process is different from the component state machine. For example, the process may be already terminated, but the component is in Ready state. This is the case if the component is configured to be ready when the underlying process is terminated.

SCORE applications use the Lifecycle Interface for reporting the “Running” state to signal they finished their initialization. This transitions the process state machine from state Starting to state Running. For Native applications which do not report their state, the process state machine advances directly to Running after successful start of the process.

Simplified example dependency graph#

Consider the following simplified dependency graph for the sequence diagrams in the following chapters.

The purpose of the is not to show a real-world setup, but only to showcase different scenarios.

The Component setup_filesystems starts a shell script setup_filesystems.sh and reaches its Ready state when the script completed. The Component random starts a binary /bin/random and is considered Ready when the file /dev/random exists. The Component app1 starts a binary /opt/bin/app1 and is considered Ready when the process signaled its Running state via the Lifecycle API. The Component StateManager starts a binary /opt/bin/sm and is considered Ready when the process signaled its Running state via the Lifecycle API.