Skip to content

Prioritizing service order

Prioritizing service order

Although systemd can start services in parallel, you can optimize service ordering by adjusting the dependency parameters in service unit files so that certain services will wait on other services to start before loading themselves. In this procedure, for example, you will create Quadlet unit files for the engine and radio services to configure their respective boot order.

Prerequisites

Procedure

  1. Create Quadlet unit files for the radio-service and engine-service services in your sample application auto-apps:

    console title="engine.container file" --8<-- "demos/engine.container"

    Note

    Requires=routingmanagerd.service is a hard dependency that prevents the engine service from starting until the routing manager service is active. After=routingmanagerd.service is an ordering dependency: the engine service starts only after the routing manager service has started.

    console title="radio.container file" --8<-- "demos/radio.container"

    Note

    Requires=routingmanagerd.service is a hard dependency that prevents the radio service from starting until the routing manager service is active. Wants=engine.service is a soft dependency. Ideally, the engine service activates the radio service, but if the engine service is not activated, systemd still permits the radio service to start.

  2. Create an Automotive Image Builder manifest named quadlet_radio_engine.aib.yml that contains the following code, which copies the Quadlet unit files to the /etc/containers/systemd/ directory during the build process:

    yaml title="Manifest configuration to copy Quadlet unit files" --8<-- "demos/quadlet_radio_engine/quadlet_radio_engine.aib.yml"

    Note

    The path: option resolves a relative path. In this example, your Quadlet unit files are in the ../ directory.

  3. Run aib-dev build to build a disk image:

    console $ aib-dev build \ --distro autosd10 \ --target qemu \ --build-dir=_build \ quadlet_radio_engine.aib.yml \ quadlet_radio_engine.qcow2

  4. Verify that the script has created an AutoSD image file named quadlet_radio_engine.qcow2 in your present working directory.

  5. Run the image:

    console $ air --nographics quadlet_radio_engine.qcow2

  6. After the image boots, log in to the VM with the user name root and the password password.

  7. From the VM, confirm the engine service started:

    ```console

    systemctl status engine.service

    ● engine.service - Demo engine service container Loaded: loaded (/etc/containers/systemd/engine.container; generated) Active: active (running) since Mon 2025-09-08 19:40:33 UTC; 7min ago ... ```

  8. List the dependencies for the engine service. The solid dot (●) to the left of routingmanagerd.service indicates that the service, which engine.service requires to start, is active:

    ```console

    systemctl list-dependencies engine.service

    engine.service ● ├─routingmanagerd.service ● ├─system.slice ● ├─network-online.target ○ │ └─NetworkManager-wait-online.service ● └─sysinit.target ... ```

  9. Confirm the radio service started:

    ```console

    systemctl status radio.service

    ● radio.service - Demo radio service container Loaded: loaded (/etc/containers/systemd/radio.container; generated) Active: active (running) since Mon 2025-09-08 19:40:33 UTC; 28s ago ... ```

  10. List the dependencies for the radio service. The solid dot (●) to the left of engine.service indicates that the engine service is active:

    ```console

    systemctl list-dependencies radio.service

    radio.service ● ├─engine.service ● ├─routingmanagerd.service ● ├─system.slice ● ├─network-online.target ○ │ └─NetworkManager-wait-online.service ● └─sysinit.target ... ```