From 681f25897c6314d24b5003e7942b7cb6d3b6d00c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicolas=20Fu=C3=9Fberger?= Date: Fri, 19 Jun 2026 09:29:48 +0200 Subject: [PATCH 1/3] First version of new README file --- README.md | 568 +++++++--------------------------- examples/README.md | 4 + lifecycle_overview.drawio.svg | 4 + 3 files changed, 112 insertions(+), 464 deletions(-) create mode 100644 lifecycle_overview.drawio.svg diff --git a/README.md b/README.md index 6cda8174e..4f73e4dd9 100644 --- a/README.md +++ b/README.md @@ -1,531 +1,171 @@ -# Overview +# Lifecycle & Health -Portable and high-performance implementation of a Lifecycle feature for S-CORE project. +## Overview + +[![Lifecycle Feature](https://img.shields.io/badge/Eclipse-Score-orange.svg)](https://eclipse-score.github.io/score/main/features/lifecycle/index.html) -This repository contains source code for Launch Manager and Health Monitor. Lifecycle feature is implemented in C++ language, but Rust language bindings are also provided. Additionally, to demonstrate how to use Lifecycle, a set of example applications can be found in ``examples`` folder. +Portable and high-performance implementation of a Lifecycle feature for S-CORE project. High level functionality provided by Lifecycle: * **Launch Manager** - * **Portability**: Compatible with multiple operating systems including Linux, QNX7, and QNX8. - * **Process Group Management**: Applications can be grouped into ProcessGroups, which are managed collectively as a single unit. - * **Startup and Shutdown Dependencies**: The order of application startup and shutdown is determined by predefined dependency configurations. - * **Failure Recovery**: Recovery actions are initiated upon detection of abnormal process termination. -* **Health Monitor** - * **Supervision Types**: Supports Alive supervision, Deadline supervision, and Logical supervision. - * **Failure Recovery**: Recovery actions are requested to Launch Manager when supervision failures are detected. - * **Configurable Detection Timing**: The maximum failure detection time can be adjusted via a tunable supervision evaluation cycle. + * **Portability**: LaunchManager works with multiple operating systems including Linux, QNX7, and QNX8. + * **Component Lifecycle Control**: Spawning and terminating OS processes according to their configured parameters (executable path, user/group identity, environment, scheduling policy). + * **Run Target Management**: Determining which components are active at any given time by activating and deactivating named Run Targets in response to requests from a StateManager. + * **Dependency Resolution**: Ensuring components start and stop in the correct order based on declared startup and shutdown dependencies. + * **Failure Recovery**: Detecting unexpected process termination and executing configured recovery actions such as restarting a component or switching to a recovery Run Target. * **External Watchdog Integration**: Compatible with external watchdogs through configurable watchdog device file. +* **Health Monitor** + * **Supervision Types**: Supports Heartbeat, Deadline, and Logical supervision to verify the timing and control flow of process execution. + * **Alive Notifications**: Supervision results are translated into alive notifications sent to the Launch Manager to communicate supervision status and report failures. -![Lifecycle Management Overview](images/lcm_overview.png) - -# Getting Started - -This section contains information on how to build and use Lifecycle feature. - -## Prerequisites - -* C++ Compiler: gcc/clang with C++17 support -* Rust Version: 1.85 (edition 2021) -* Build System: Bazel -* Operating System: Linux (Ubuntu 22.04+) -* Dependencies: S-Core Baselibs, Google Flatbuffers, libacl1-dev -* Dependencies of example applications: Docker, Python (3.12) - -## Building the project +## Public APIs -It is recommended to use the devcontainer for building the project, see [eclipse-score/devcontainer/README.md#inside-the-container](https://github.com/eclipse-score/devcontainer/blob/main/README.md#inside-the-container) +![High Level Overview](lifecycle_overview.drawio.svg) -Build all components for **Linux** by running +**Health Monitoring API** ```sh -bazel build --config=x86_64-linux //... +//score/health_monitor:health_monitoring_cc +//score/health_monitor:health_monitoring_rust ``` -To test launch_manager and health_monitor with the sanitizers enabled use one of the following +The Health Monitoring library provides APIs for the following supervisions: +* Heartbeat Supervision +* Deadline Supervision +* Logical Supervision -ASan + UBSan + LSan (recommended): +These supervision results are translated to alive notifications that are sent to the Launch Manager via its *Alive API*. -```sh -bazel test --config=asan_ubsan_lsan --config=x86_64-linux //score/... //tests/... -``` +See the [C++ Supervised Example Application](examples/rust_supervised_app) and [Rust Supervised Example Application](examples/rust_supervised_app). -To build all components with ``score::mw::log`` enabled, use this command: +**Alive API** ```sh -bazel build --config=x86_64-linux --cxxopt=-DLC_LOG_SCORE_MW_LOG //... +//score/launch_manager:alive_cc +//score/launch_manager:alive_rust ``` -## IDE support - -### C++ -Use Visual Studio Code with `clangd`. Make sure you don't have the MS C++ IntelliSense extension installed as this is likely to clash with `clangd`. -Then you need to call `./scripts/generate_cpp_compile_commands.sh` to generate compilation DB for clangd and restart it in VS Code. Indexing shall work. - -### Rust - +The *Alive API* allows to report alive notifications to the Launch Manager. +Applications may either use the higher-level *Health Monitoring APIs* or directly report alive notifications to the Launch Manager via the *Alive API*. -### QNX - -#### Envionment Setup -Either add to ~/.netrc -```sh -machine qnx.com -login -password -``` -(Makes sure your netrc has the right permissions `chmod 600 ~/.netrc`) - -Or export env vars: -```sh -export SCORE_QNX_USER= -export SCORE_QNX_PASSWORD= -``` -Also if you are not running on the devcontainer make sure the qnx license -is in the correct directory: +**Lifecycle API** ```sh -sudo mkdir /opt/score_qnx/license -cp -r ~/.qnx/license/* /opt/score_qnx/license -sudo chmod 777 -R /opt/score_qnx/ +//score/launch_manager:lifecycle_cc +//score/launch_manager:lifecycle_rust ``` -Next make the `~/.bazelrc` that contains the following: -`common --action_env=QNXLM_LICENSE_FILE=` +Applications can report the *Running state* to the Launch Manager to signal that initialization is finished and dependent applications can now be started. -#### Build +Application may either use the higher-level [``score::mw::lifecycle::Application``](score/launch_manager/src/lifecycle_client/src/application.h) API or the lower level [``score::mw::lifecycle::report_running``](score/launch_manager/src/lifecycle_client/src/report_running.h) function. -##### Fetch QNX SDP +See examples [Application Example](examples/cpp_lifecycle_app) and [report_running example](examples/cpp_supervised_app). -Note: For the next command if you are getting checksum mismatch errors then its -possible you need to agree the terms and condition of the SDP by clicking the -URL in the error message and completing the form. +**Control API** ```sh -bazel fetch @score_toolchains_qnx//... -cred_helper="$(find -L $(bazel info output_base)/external -name qnx_credential_helper.py -print -quit)" -bazel fetch @toolchains_qnx_sdp//... --credential_helper=*.qnx.com="$cred_helper" +//score/launch_manager:control_cc ``` -##### Build For QNX +The *Control API* is intended for implementing a State Manager that controls which *Run Target* is currently active. -```sh -bazel build --config=x86_64-qnx -- //score/... -bazel build --config=arm64-qnx -- //score/... -``` +See the [Example StateManager](examples/control_application). -## Running Lifecycle feature and example applications - -The ``examples`` folder contains the automated demo verification for the example applications, together with the configuration and packaged binaries it needs. Launch Manager starts Health Monitor and the configured applications as part of the test. For more information see [examples/README.md](examples/README.md). - -## Configuration - -Lifecycle feature is configured by json files. - -Following json code demonstrates Launch Manager configuration. Key elements of the configuration: - - * A single process group is configured (``MainPG``), with three states. - * A single process is configured with ``LD_LIBRARY_PATH`` environmental variable and no command line arguments. - * The configured process will run in ``Startup`` and ``Recovery`` state. - -```json -{ - "versionMajor": 7, - "versionMinor": 0, - "Process": [ - { - "identifier": "healthmonitor", - "uid": 0, - "gid": 0, - "path": "/opt/health_monitor/health_monitor", - "functionClusterAffiliation": "STATE_MANAGEMENT", - "numberOfRestartAttempts": 0, - "executable_reportingBehavior": "ReportsExecutionState", - "sgids": [], - "startupConfig": [ - { - "executionError": "1", - "schedulingPolicy": "SCHED_OTHER", - "schedulingPriority": "0", - "identifier": "health_monitor_startup_config", - "enterTimeoutValue": 20000, - "exitTimeoutValue": 1000, - "terminationBehavior": "ProcessIsNotSelfTerminating", - "executionDependency": [], - "processGroupStateDependency": [ - { - "stateMachine_name": "MainPG", - "stateName": "MainPG/Startup" - }, - { - "stateMachine_name": "MainPG", - "stateName": "MainPG/Recovery" - } - ], - "environmentVariable": [ - { - "key": "LD_LIBRARY_PATH", - "value": "/opt/lib" - } - ], - "processArgument": [] - } - ] - } - ], - "ModeGroup": [ - { - "identifier": "MainPG", - "initialMode_name": "Off", - "recoveryMode_name": "MainPG/Recovery", - "modeDeclaration": [ - { - "identifier": "MainPG/Off" - }, - { - "identifier": "MainPG/Startup" - }, - { - "identifier": "MainPG/Recovery" - } - ] - } - ] -} -``` +**Launch Manager** -For the convenience of the end user, a python module is provided for Launch Manager. Following code demonstrates Launch Manager configuration. Key elements of the configuration: - - * A single machine is configured with, global ``LD_LIBRARY_PATH`` environmental variable. - * A single process group is configured (``MainPG``), with three states. - * 50 processes are configured, each with unique UID and GID. - * All processes are started from the same executable. - * All processes will be started in ``Startup`` state of ``MainPG`` process group. - * Each process has its own ``PROCESSIDENTIFIER`` environmental variable. Value of that variable is different for each process. - * Only second process has command line argument configured. - -```python -conf_gen = LaunchManagerConfGen() -qt_am_machine = conf_gen.add_machine("qt_am_machine", - env_variables = {"LD_LIBRARY_PATH": "/opt/lib"}) - -pg_machine = conf_gen.machine_add_process_group(qt_am_machine, - "MainPG", ["Off", "Startup", "Recovery"]) - -for i in range(50): - cpp_lifecycle_app = conf_gen.process_group_add_process(pg_machine, - f"{process_group_name}_cpp_lifecycle_app{i}", - executable_name = "/opt/cpp_lifecycle_app/cpp_lifecycle_app", - uid = 1000 + i, - gid = 1000 + i) - conf_gen.process_add_startup_config(cpp_lifecycle_app, - f"cpp_lifecycle_app_startup_config_{i}", - process_arguments = ["-c", "2000"] if i == 1 else [], - env_variables = {"PROCESSIDENTIFIER": f"{process_group_name}_lc{i}"}, - scheduling_policy = "SCHED_OTHER", - scheduling_priority = 0, - enter_timeout = 5.0, - exit_timeout = 2.0, - use_in = ["Startup"]) - -conf_gen.generate_json("./lm_demo.json") +```sh +//score/launch_manager:launch_manager ``` -Following json code demonstrates Health Monitor configuration. Key elements of the configuration: - - * Single process is supervised. - * Alive, deadline and logical supervision is configured for that process. - * Single process group is configured. - * Recovery action for that process group is configured. - -Sample configuration of the monitored application: -```json -{ - "versionMajor": 8, - "versionMinor": 0, - "process": [], - "hmMonitorInterface": [ - { - "instanceSpecifier": "demo/demo_application0/Port1", - "processShortName": "demo_application0", - "portPrototype": "Port1", - "interfacePath": "demo_application_0_MainPG", - "refProcessIndex":0 - } - ] -} -``` +The *launch_manager* target contains the daemon executable. -Sample configuration of Health Monitor daemon: -```json -{ - "versionMajor": 8, - "versionMinor": 0, - "process": [ - { - "index": 0, - "shortName": "demo_application0", - "identifier": "demo_app0_MainPG", - "processType": "REGULAR_PROCESS", - "refProcessGroupStates": [ - { - "identifier": "MainPG/Startup" - } - ], - "processExecutionErrors": [ - { - "processExecutionError": 1 - } - ] - } - ], - "hmMonitorInterface": [ - { - "instanceSpecifier": "demo/demo_application0/Port1", - "processShortName": "demo_application0", - "portPrototype": "Port1", - "interfacePath": "demo_application_0_MainPG", - "refProcessIndex": 0, - "permittedUid": 0 - } - ], - "hmSupervisionCheckpoint": [ - { - "shortName": "Checkpoint0_1", - "checkpointId": 1, - "refInterfaceIndex": 0 - }, - { - "shortName": "Checkpoint0_2", - "checkpointId": 2, - "refInterfaceIndex": 0 - }, - { - "shortName": "Checkpoint0_3", - "checkpointId": 3, - "refInterfaceIndex": 0 - } - ], - "hmAliveSupervision": [ - { - "ruleContextKey": "AliveSupervision0", - "refCheckPointIndex": 0, - "aliveReferenceCycle": 100.0, - "minAliveIndications": 1, - "maxAliveIndications": 3, - "isMinCheckDisabled": false, - "isMaxCheckDisabled": false, - "failedSupervisionCyclesTolerance": 1, - "refProcessIndex": 0, - "refProcessGroupStates": [ - { - "identifier": "MainPG/Startup" - } - ] - } - ], - "hmDeadlineSupervision": [ - { - "ruleContextKey": "DeadlineSupervision0", - "maxDeadline": 80.0, - "minDeadline": 40.0, - "checkpointTransition": { - "refSourceCPIndex": 0, - "refTargetCPIndex": 1 - }, - "refProcessIndices": [ - 0 - ], - "refProcessGroupStates": [ - { - "identifier": "MainPG/Startup" - } - ] - } - ], - "hmLogicalSupervision": [ - { - "ruleContextKey": "LogicalSupervision0", - "checkpoints": [ - { - "refCheckPointIndex": 0, - "isInitial": true, - "isFinal": false - }, - { - "refCheckPointIndex": 1, - "isInitial": false, - "isFinal": false - }, - { - "refCheckPointIndex": 2, - "isInitial": false, - "isFinal": true - } - ], - "transitions": [ - { - "checkpointSourceIdx": 0, - "checkpointTargetIdx": 1 - }, - { - "checkpointSourceIdx": 1, - "checkpointTargetIdx": 2 - } - ], - "refProcessIndices": [ - 0 - ], - "refProcessGroupStates": [ - { - "identifier": "MainPG/Startup" - } - ] - } - ], - "hmLocalSupervision": [ - { - "ruleContextKey": "LocalSupervision0", - "infoRefInterfacePath": "demo_application_0", - "hmRefAliveSupervision": [ - { - "refAliveSupervisionIdx": 0 - } - ], - "hmRefDeadlineSupervision": [ - { - "refDeadlineSupervisionIdx": 0 - } - ], - "hmRefLogicalSupervision": [ - { - "refLogicalSupervisionIdx": 0 - } - ] - } - ], - "hmGlobalSupervision": [ - { - "ruleContextKey": "GlobalSupervision_MainPG", - "isSeverityCritical": false, - "localSupervision": [ - { - "refLocalSupervisionIndex": 0 - } - ], - "refProcesses": [ - { - "index": 0 - } - ], - "refProcessGroupStates": [ - { - "identifier": "MainPG/Startup" - } - ] - } - ], - "hmRecoveryNotification": [ - { - "shortName": "RecoveryNotification_MainPG", - "recoveryNotificationTimeout": 4000.0, - "processGroupMetaModelIdentifier": "MainPG/Recovery", - "refGlobalSupervisionIndex": 0, - "instanceSpecifier": "", - "shouldFireWatchdog": false - } - ] -} -``` +The Launch Manager is configured with a json file that is compiled to a binary format using the bazel macro: -Full configuration for example applications can be found in ``examples/demo_verification/lifecycle_demo_test.json``. +```python +load("//:defs.bzl", "launch_manager_config") -# Architecture +launch_manager_config( + name = "examples_test_config", + config = ":lifecycle_demo_test.json", + flatbuffer_out_dir = "etc", +) +``` -The Lifecycle feature is divided in to two logical components, Launch Manager and Health Monitor. In our solution each component is implemented as a separate daemon. +See the [demo scenario](examples/demo_verification) for an example. -## Launch Manager architecture +**Mocks** -Following diagram shows high level overview of Launch Manager architecture. -![Launch Manager architecture overview](images/lm_arch_overview.png) +```sh +//score/launch_manager:applicationcontext_mock_cc +//score/launch_manager:lifecycle_mock_cc +//score/launch_manager:report_running_mock_cc +``` -Main components are: - * **Control client library:** Library used to control states of Process Groups. Each Process Group has a set of states that could be activated or switched off. This library can be used to control states of Process Groups from C++ or Rust application. Please note that by controlling Process Group states, we are starting or stopping applications. Rights to use this library has to be assigned during configuration step, otherwise an attempt to use this interface will be blocked. - * **Lifecycle client library:** Library used by S-CORE applications, to report application states back to Launch Manager. Every non native application should use this interface. This interface is available in C++ and Rust language. - * **Configuration manager:** Small portability layer, designed to protect business logic from changes in configuration format. Current implementation reads data from FlatBuffers files and populate internal data structures. - * **OS abstraction layer (OSAL):** Portability layer designed to protect business logic, from differences in POSIX based OSs. At the moment we support ``Linux`` based OSs and ``QNX``. It is worth to note, that we follow ``fork`` then ``exec`` path, when starting new processes. This approach provides greater flexibility than the ``spawn`` method, particularly when setting up the execution environment and access rights for child processes. - * **Process Group manager:** Business logic is implemented in Process Group manager. Following diagram shows high level overview, of this component. +## Documentation -![Process Group manager architecture overview](images/process_group_manager_arch_overview.png) +* [Lifecycle Feature Documentation](https://eclipse-score.github.io/score/main/features/lifecycle/index.html) +* [Lifecycle Module Documentation](https://eclipse-score.github.io/lifecycle/main/) -Key components of Process Group manager are: - * **OS Handler:** A simple thread tasked with collecting exit status of child processes. As soon as exit status of a child process becomes available, we collect it and pass that information to the Process Group manager. - * **Process Group:** Graph that holds information about processes that belongs to a particular Process Group. This is the place where we store start-up configuration, the information on how to start a process, as well as information on when to start a process. - * **Thread pool / Job queue:** This is our scalability engine. By controlling queue size and number of threads, we can scale up and scale down (in line with hardware capabilities we are running on). - * **Worker thread:** A simple wrapper around POSIX thread. It will fetch a job from a queue, if there is anything to be done, or sleep otherwise. - * **Process Group Manager:** This is where main business logic is implemented. This thread will service all external communication channels and if there is a Process Group state change requested, it will add initial process start to the queue. When thread pool process all start / stop operations, this component will send response to the requesting Control client library. If a Process Group end up in an error state, and there is no active request from outside, Process Group manager will execute a recovery action. +## Getting Started -## Health Monitor architecture +### Building -Following diagram shows high level overview of Health Monitor architecture. -![Health Monitor architecture overview](images/hm_arch_overview.png) +It is recommended to use the devcontainer for building the project, see [eclipse-score/devcontainer/README.md#inside-the-container](https://github.com/eclipse-score/devcontainer/blob/main/README.md#inside-the-container) - * **Health Monitor library (hm lib):** Library used by supervised applications to report checkpoints, that have been configured for monitoring. This library executes without a background thread, so we can avoid forced context switches when application reports a checkpoint. - * **Configuration:** Portability layer designed to shield business logic from changes in configuration format. Its implementation follows factory design pattern. We read data from FlatBuffers files and return fully initialized objects. - * **Supervision:** This component periodically reads all reported checkpoints from shared memory and evaluates supervision status for each configured process. Upon detection of an error condition, the recovery component is triggered to initiate appropriate corrective actions. - * **Recovery:** When an error is detected by supervision component, recovery component will perform preconfigured recovery action. - * **Watchdog:** This component is responsible for the initialization, control, and servicing of the external watchdog. +Build all components for different platforms: -The Health Monitor is implemented as a single-threaded process. The frequency at which the supervision component evaluates reported checkpoints can be configured via a dedicated parameter. This configurability enables optimization of CPU utilization against worst-case fault detection latency. Depending on the target hardware platform, a trade-off can be made between detection time and CPU consumption. +**QNX** -The external watchdog abstraction layer is implemented using the ``/dev/watchdog`` device interface, which is commonly available on Linux-based operating systems. For QNX environments, the same interface can be implemented using a resource manager. +```sh +bazel build --config=x86_64-qnx //... +bazel build --config=arm64-qnx //... +``` +**Linux** -# Requirements coverage +```sh +bazel build --config=x86_64-linux //... +bazel build --config=arm64-linux //... +``` -This overview represent a high level illustration of requirements coverage and is not a traceability view. Full list of requirement can be found here: [Lifecycle Requirements](https://eclipse-score.github.io/score/main/features/lifecycle/requirements/index.html). +### Testing -## ✅ Launch Manager features +```sh +bazel test --config=x86_64-linux //score/... //tests/... +``` -### Process management Capabilities +Run Tests with Sanitizer: ASan + UBSan + LSan (recommended): - - Launch processes with dependency ordering ✅ - - Parallel execution & Multiple instances of executables ✅ - - UID/GID, Security policy and scheduler configuration ✅ - - Timeouts & Retry on process startup ✅ - - Validate dependency consistency (Tooling / startup) ⏳ - - OCI compliance, ASLR support & process adoptions ⏳ +```sh +bazel test --config=asan_ubsan_lsan --config=x86_64-linux //score/... //tests/... +``` -### Run targets & Conditional Launching +### Demo - - Define, Launch & Switch between named run targets ✅ - - Launch based on conditions (run targets / dependencies), Debug mode ✅ - - Configurable timeouts and polling intervals for conditions ⏳ - - Pre/post-start validation ⏳ - - Define process dependencies and stop sequences (dependency based) ✅ +See instructions [here](examples/README.md) on how to execute a demo scenario. -### Process Termination +## Repository Structure - - Configurable stop timeout ✅ - - Terminate based on dependency order ✅ - - SIGTERM/SIGKILL delay ✅ - - Normal, slow, fast shutdown modes ⏳ +``` +score_lifecycle/ +├── score/ # Lifecycle implementation +│ ├── launch_manager/ # Launch Manager daemon + library implementation + unit/component tests +│ └── health_monitor/ # Health Monitoring library implementation + unit/component tests +├── external/ # Third party software +├── examples/ # Example applications +├── scripts/ # Launch Manager Configuration generation +└── tests/ # Feature Integration tests +``` -### Control Interface +## Contributing - - Allow external users to send control commands (activate, Stop, etc..) ✅ - - Request run target launch ✅ - - Component state reporting ⏳ - - Report & query component status (started/running/degraded) ⏳ +We welcome contributions! See our [Contributing Guide](CONTRIBUTION.md) for details. -## ✅ Health monitor features +## Support -### Monitoring & Recovery +### Community +- **Issues**: Report bugs and request features via [GitHub Issues](https://github.com/eclipse-score/lifecycle/issues) +- **Discussions**: Join lifecycle [slack channel](https://sdvworkinggroup.slack.com/archives/C094Z3BN1K4) - - Abnormal process termination detection ✅ - - Timing & logical monitoring ✅ - - Drop supervision ✅ - - Recovery actions (run target switch & process relaunch) ⏳ - - Configurable recovery wait time ✅ - - External monitor notifications & watchdog support ✅ - - Internal monitoring (self-health) checks ✅ +--- diff --git a/examples/README.md b/examples/README.md index 76ed4336c..2b436ac0c 100644 --- a/examples/README.md +++ b/examples/README.md @@ -25,3 +25,7 @@ The test verifies the following scenarios end-to-end: | `rust_supervised_app` | Rust app with alive supervision and crash recovery | | `cpp_lifecycle_app` | C++ app demonstrating basic lifecycle management | | `control_daemon` | State Manager app for requesting RunTarget transitions | + +## Launch Manager Configuration + +See the [Launch Manager Configuration](examples/demo_verification/lifecycle_demo_test.json) for the demo scenario. \ No newline at end of file diff --git a/lifecycle_overview.drawio.svg b/lifecycle_overview.drawio.svg new file mode 100644 index 000000000..54f69ee41 --- /dev/null +++ b/lifecycle_overview.drawio.svg @@ -0,0 +1,4 @@ + + + +
Application
Application
Launch Manager
Launch Manager
StateManager
StateManager
Switch
RunTarget
Switch...
config.bin
config.b...
Alive Notification
Alive No...
Running
State
Running...
Notify
RunTarget
Change
Notify...
Health Monitoring
Health Monitori...
Control
Control
Alive
Alive
ReportRunning
ReportRunning
Lifecycle
Lifecycle
Request
Termination
Request...Text is not SVG - cannot display \ No newline at end of file From 127a1be834d215bfde5d2d12acf7a82e6dd81948 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicolas=20Fu=C3=9Fberger?= Date: Fri, 19 Jun 2026 11:30:15 +0200 Subject: [PATCH 2/3] Improvements --- README.md | 30 +++++++++++++++--------------- examples/README.md | 2 +- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 4f73e4dd9..db597d091 100644 --- a/README.md +++ b/README.md @@ -4,13 +4,13 @@ [![Lifecycle Feature](https://img.shields.io/badge/Eclipse-Score-orange.svg)](https://eclipse-score.github.io/score/main/features/lifecycle/index.html) -Portable and high-performance implementation of a Lifecycle feature for S-CORE project. +Portable and high-performance implementation of the Lifecycle feature for the S-CORE project. High level functionality provided by Lifecycle: * **Launch Manager** * **Portability**: LaunchManager works with multiple operating systems including Linux, QNX7, and QNX8. - * **Component Lifecycle Control**: Spawning and terminating OS processes according to their configured parameters (executable path, user/group identity, environment, scheduling policy). + * **Component Lifecycle Control**: Spawning and terminating OS processes according to their configured parameters (executable path, user/group identity, environment, scheduling policy, etc.). * **Run Target Management**: Determining which components are active at any given time by activating and deactivating named Run Targets in response to requests from a StateManager. * **Dependency Resolution**: Ensuring components start and stop in the correct order based on declared startup and shutdown dependencies. * **Failure Recovery**: Detecting unexpected process termination and executing configured recovery actions such as restarting a component or switching to a recovery Run Target. @@ -25,7 +25,7 @@ High level functionality provided by Lifecycle: **Health Monitoring API** -```sh +``` //score/health_monitor:health_monitoring_cc //score/health_monitor:health_monitoring_rust ``` @@ -37,34 +37,34 @@ The Health Monitoring library provides APIs for the following supervisions: These supervision results are translated to alive notifications that are sent to the Launch Manager via its *Alive API*. -See the [C++ Supervised Example Application](examples/rust_supervised_app) and [Rust Supervised Example Application](examples/rust_supervised_app). +See the [C++ Supervised Example Application](examples/cpp_supervised_app) and [Rust Supervised Example Application](examples/rust_supervised_app). **Alive API** -```sh +``` //score/launch_manager:alive_cc //score/launch_manager:alive_rust ``` -The *Alive API* allows to report alive notifications to the Launch Manager. +The *Alive API* allows applications to report alive notifications to the Launch Manager. Applications may either use the higher-level *Health Monitoring APIs* or directly report alive notifications to the Launch Manager via the *Alive API*. **Lifecycle API** -```sh +``` //score/launch_manager:lifecycle_cc //score/launch_manager:lifecycle_rust ``` Applications can report the *Running state* to the Launch Manager to signal that initialization is finished and dependent applications can now be started. -Application may either use the higher-level [``score::mw::lifecycle::Application``](score/launch_manager/src/lifecycle_client/src/application.h) API or the lower level [``score::mw::lifecycle::report_running``](score/launch_manager/src/lifecycle_client/src/report_running.h) function. +Applications may either use the higher-level [``score::mw::lifecycle::Application``](score/launch_manager/src/lifecycle_client/src/application.h) API or the lower level [``score::mw::lifecycle::report_running``](score/launch_manager/src/lifecycle_client/src/report_running.h) function. See examples [Application Example](examples/cpp_lifecycle_app) and [report_running example](examples/cpp_supervised_app). **Control API** -```sh +``` //score/launch_manager:control_cc ``` @@ -74,15 +74,15 @@ See the [Example StateManager](examples/control_application). **Launch Manager** -```sh +``` //score/launch_manager:launch_manager ``` The *launch_manager* target contains the daemon executable. -The Launch Manager is configured with a json file that is compiled to a binary format using the bazel macro: +The Launch Manager is configured with a JSON file that is compiled to a binary format using the bazel macro: -```python +```starlark load("//:defs.bzl", "launch_manager_config") launch_manager_config( @@ -96,7 +96,7 @@ See the [demo scenario](examples/demo_verification) for an example. **Mocks** -```sh +``` //score/launch_manager:applicationcontext_mock_cc //score/launch_manager:lifecycle_mock_cc //score/launch_manager:report_running_mock_cc @@ -111,7 +111,7 @@ See the [demo scenario](examples/demo_verification) for an example. ### Building -It is recommended to use the devcontainer for building the project, see [eclipse-score/devcontainer/README.md#inside-the-container](https://github.com/eclipse-score/devcontainer/blob/main/README.md#inside-the-container) +It is recommended to use the devcontainer for building the project. See [eclipse-score/devcontainer/README.md#inside-the-container](https://github.com/eclipse-score/devcontainer/blob/main/README.md) for setup instructions. Build all components for different platforms: @@ -135,7 +135,7 @@ bazel build --config=arm64-linux //... bazel test --config=x86_64-linux //score/... //tests/... ``` -Run Tests with Sanitizer: ASan + UBSan + LSan (recommended): +Run tests with sanitizers: ASan + UBSan + LSan (recommended): ```sh bazel test --config=asan_ubsan_lsan --config=x86_64-linux //score/... //tests/... diff --git a/examples/README.md b/examples/README.md index 2b436ac0c..a4084fc2c 100644 --- a/examples/README.md +++ b/examples/README.md @@ -28,4 +28,4 @@ The test verifies the following scenarios end-to-end: ## Launch Manager Configuration -See the [Launch Manager Configuration](examples/demo_verification/lifecycle_demo_test.json) for the demo scenario. \ No newline at end of file +See the [Launch Manager Configuration](demo_verification/lifecycle_demo_test.json) for the demo scenario. \ No newline at end of file From 63699172813cabb7e8478c28a13e2469d012f4fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicolas=20Fu=C3=9Fberger?= Date: Thu, 25 Jun 2026 08:02:19 +0200 Subject: [PATCH 3/3] Remove QNX7 reference --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index db597d091..d52c89909 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ Portable and high-performance implementation of the Lifecycle feature for the S- High level functionality provided by Lifecycle: * **Launch Manager** - * **Portability**: LaunchManager works with multiple operating systems including Linux, QNX7, and QNX8. + * **Portability**: LaunchManager works with multiple operating systems including Linux and QNX8. * **Component Lifecycle Control**: Spawning and terminating OS processes according to their configured parameters (executable path, user/group identity, environment, scheduling policy, etc.). * **Run Target Management**: Determining which components are active at any given time by activating and deactivating named Run Targets in response to requests from a StateManager. * **Dependency Resolution**: Ensuring components start and stop in the correct order based on declared startup and shutdown dependencies.