Runtime Architecture

Legato's runtime architecture manages each app in its own sandbox.

conceptsRuntimeArch_LayeredArchitecture.png

Apps communicate with each other using access-controlled message-passing services.

The Supervisor automatically creates sandboxes.

Applications

An application (we call them 'apps') is a collection of executable files, libraries, and/or other resource files (e.g., audio files, web pages) that can be deployed to a target device. Once installed on a device, an app can be started and stopped.

By default, each app runs in its own sandbox. When an app is constructed, all the files and IPC services it needs to access are declared. At runtime, the Supervisor and the Service Directory enforce that only approved files and IPC services are accessed by that app.

Tutorials

Supervisor

The Supervisor is a privileged process running on the target device that:

  • creates and destroys conceptsSecuritySandbox for apps
  • starts and stops apps
  • performs fault recovery when apps fail (e.g., restarting the app).

Service Directory

Legato's Service Directory provides a secure way for client processes to find servers offering services they need, which ensures only authorized connections are established.

Services APIs
Interfaces

Config Tree

The Config Tree provides persistent basicConfig data storage organized in a tree structure.

Command line config tool
Config Tree API

Watchdog

Legato provides a monitoring service for applications with the watchdog daemon which runs within the Legato Runtime Environment. If your target supports it, the watchdog daemon can also be enabled to kick an external watchdog such as Linux watchdog device.

Note
To configure the external watchdog kick interval, add a externalWatchdogKick section to your systems System Definition .sdef .

The daemon monitors app's processes for hangs or freezing and if the process doesn't "kick" the watchdog daemon in a specified time (the default is 30 seconds), the watchdog signals the Supervisor to perform a specified action. Critical services should also set the maxWatchdogTimeout to further ensure that the system is running with all critical services started.

Note
Most platform services installed on your target have a maxWatchdogTimeout set to 2 minutes. To enable, configure or disable watchdog on a platform service, configure the watchdog settings in the platform service's Application Definition .adef.

The watchdog consists of 3 configurable settings:

  • timeout: the time the watchdog daemon waits for a "kick" in normal operation.
  • maxTimeout: the maximum time the watchdog daemon waits for a kick (including on startup, when performing a system recovery, and after le_wdog_Timeout()).
  • action: the action the watchdog daemon takes when it does not receive a "kick".

All settings are configured in the app's definition file (.adef). You must also bind the watchdog API into your app and use the Watchdog Service API's functions to configure the behavior of the watchdog and the app.

Note
Setting the maxTimeout also ensures the watchdog is started on system boot (rather than the first instance of le_wdog_Kick()).

Default watchdog kick timeout: 30 seconds

Default watchdog action: restart

Possible watchdog actions:

  • ignore - Supervisor just logs a warning message; no further action taken.
  • restart - log a critical message and restart the process.
  • restartApp - log a critical message and restart the entire app.
  • stop - Supervisor terminates the process if it's still running.
  • stopApp - log a critical message and terminate the entire app (send all processes the SIGTERM signal, followed shortly by SIGKILL).
  • reboot - log an emergency message and reboot the system.

To disable the watchdog for all the daemons within the Legato Application Framework, disable the WDOG_FRAMEWORK setting in the Legato KConfig.

To disable the watchdog for the Platform Services on your target disable the SERVICES_WATCHDOG setting in the legato KConfig.

Logs

Legato provides a user-friendly way to control log message filtering for running app processes.

Command line log tool
Logging API.

Update Daemon

The Update Daemon accepts update pack files that contain software/firmware update instructions and associated data like libraries, executables, and resource files.

Update packs can be fed to the Update Daemon through the Update API API or through the update tool.

The Update Daemon includes hooks that allow update packs to be digitally signed and/or encrypted for security reasons.

Copyright (C) Sierra Wireless Inc.