Skip to content

Service ordering in AutoSD

Service ordering in AutoSD

In Linux-based operating systems (OS), systemd is the primary service manager. After the Linux kernel loads, systemd orchestrates service lifecycles, such as starting, stopping, and managing services and their dependencies. Setting the order in which services are loaded is one crucial function of systemd in automotive operating systems where boot times and reliability are critical.

Service unit files and dependencies

When you prioritize the boot order of services in systemd, consider the different types of services:

  • Early critical services are fundamental to system function and must start as soon as possible.
  • Early services run after early critical services complete and the core environment is set up.
  • Standard services, such as user-space services and daemons, start after the system reaches a stable state.

Every service is defined by a service unit file. Service unit files specify configuration details, such as binary location, arguments, and dependencies.

Dependencies are important to consider when you configure service ordering, because they control the order and sequence of service initiation as well as defining the relationship between services.

Although systemd can start services in parallel, you can optimize boot order by adjusting the dependency parameters in service unit files so that, for example, certain services will wait on other services to start before loading themselves.

These key configuration parameters help you order services according to your system's requirements:

  • Before= and After= specify an ordering dependency to ensure that a service starts either before or after another.
  • Wants= and Requires= define a "wants" or "needs" dependency. Requires= is a hard dependency, meaning if the required service fails, the current service will also fail. Wants= is a softer dependency that permits the service to start even if the target service isn't available.
  • WantedBy= and RequiredBy= are the inverse of Wants= and Requires=, respectively. They specify which services should start a given service.

By explicitly declaring dependencies, you can configure early critical services to start as soon as possible rather than relying on the parallel startup stage. Similarly, you can delay less critical services to reduce parallelism and potentially free up resources to boot essential components faster.

```console title="Example unit file" [Unit] Description=Early Boot Service DefaultDependencies=no Before=sysinit.target

[Service] Type=oneshot ExecStart=/usr/bin/cat /proc/uptime ```

This example creates an early service according to the following directives:

  • DefaultDependencies=no tells systemd not to add the implicit dependencies that standard services get.
  • Before= is an ordering dependency that directs systemd to start the service before sysinit.target is reached.
  • Type=oneshot indicates the service is a "one-shot" process, meaning it runs only once.
  • ExecStart= is the actual command the service runs.
Boot order analysis and optimization

You can optimize system performance by adjusting dependencies in service unit files. For example, you can delay less critical services to free up resources and prioritize essential components for a faster boot time.

To understand and optimize the boot process, use these systemd tools to help you analyze and debug the system:

The boot timings script is another useful resource to aid in understanding boot time performance on your system.

BlueChi and layered management

While systemd starts the entire OS and handles the direct management of services, an API called BlueChi allows automotive manufacturers to control service states at a higher level. For example, if a system administrator needs to switch the state of some services, they can use BlueChi to task systemd with starting or stopping those services.

In partitioned environments, the service management hierarchy is layered. Systemd exists in the root partition and manages the QM partition as a single process, for example, as a container started with podman. The QM partition contains a separate systemd instance that manages QM and the nested containers and services inside it. This hierarchy provides clear isolation between the root and QM partitions, with each systemd instance responsible for its respective domain.

Performance and secure boot

Boot time optimization and security are often competing priorities.

  • Performance: In automotive systems, boot time is a critical key performance indicator (KPI). Services must be prioritized as early critical, early, or standard. You must tune the dependencies and startup order carefully to meet strict timing requirements.
  • Secure boot: This security feature verifies the integrity of the OS and its components during boot. While vital for security, verification steps, such as checksums and authentications, introduce overhead that can slow down the boot process.

Note

Boot time performance can vary significantly across different hardware platforms. What works quickly on a virtual machine may not be as fast on the target hardware. Validate all optimizations for production environments.

Additional resources