Introduction: The Evolution of Init Systems in Embedded Linux

The Android operating system, at its core, leverages a customized Linux kernel. For managing system services and processes during boot-up and runtime, Android traditionally relies on its own init process, configured by init.rc scripts. These scripts, while effective for the Android ecosystem, can present challenges when integrating Android-specific services into broader, non-Android Linux distributions or highly customized embedded systems that adopt systemd. systemd, the ubiquitous init system in most modern Linux distributions, offers a robust, flexible, and powerful framework for service management. This guide explores the practicalities of migrating complex Android services, particularly those with intricate interdependencies, from the init.rc paradigm to systemd unit files, focusing on sophisticated dependency customization.

The move from init.rc to systemd is often driven by a need for standardized service management across diverse embedded Linux platforms, leveraging systemd‘s advanced features like socket activation, cgroup management, and sophisticated dependency resolution. While init.rc uses an event-driven model with implicit ordering based on script structure and ‘on’ triggers, systemd provides explicit, declarative dependency mechanisms, which can be both a blessing and a curse when dealing with deeply intertwined services.

Understanding init.rc Service Management and Dependencies

In Android’s init.rc, services are defined with their executable path, user/group, and optional capabilities. Dependencies are often implicit, relying on execution order, file system availability, or specific system properties being set. For instance, a service might be started on boot, or on property:sys.boot_completed=1, indicating a very coarse-grained dependency. Lower-level services, like HAL implementations, typically start early, and higher-level applications simply assume their availability. Explicit dependencies beyond simple ordering are largely absent, making debugging startup issues reliant on log analysis rather than a declarative framework.

Consider a hypothetical Android sensor HAL service, mysensor_hal_service, which depends on a custom kernel module, and a data_processor_service that processes data from this HAL. In init.rc, this might look like:

# /vendor/etc/init/hw/mysensor.rc (simplified example)on init    # Load the kernel module; implicitly assumed to be ready before HALservice mysensor_hal_service /vendor/bin/hw/[email protected]    class hal    user system    group system input    seclabel u:r:hal_mysensor_default:s0    # No explicit dependency on module loading, relies on 'on init' order    # Might use 'oneshot' if it needs to complete before other things, but rare for HALs    # This service is expected to always be runningon property:sys.boot_completed=1    # This service waits for boot completion, and implicitly for mysensor_hal_service to be ready.service data_processor_service /vendor/bin/data_processor    class main    user data_processor    group data_processor system    seclabel u:r:data_processor:s0    # Implicitly depends on mysensor_hal_service being active

Migrating to systemd: The Declarative Approach

systemd manages services using unit files, which are declarative configuration files specifying how to start, stop, and manage a service. The core of systemd‘s power lies in its sophisticated dependency management system, allowing for precise control over service startup order, conditions, and relationships.

A typical .service unit file has three main sections:

• [Unit]: Contains generic options about the unit, including description, documentation, and most importantly, dependency specifications like Description, Documentation, Requires, Wants, After, Before, Conflicts.
• [Service]: Defines the actual service execution parameters, such as ExecStart, ExecStop, Type (e.g., forking, simple, oneshot), User, Group, Restart policy.
• [Install]: Specifies how the unit is enabled, typically using WantedBy to declare which target unit should pull this service into the boot process (e.g., multi-user.target).

Translating Complex Dependencies to systemd

Let’s migrate our example services. We’ll break it down into three units:

1. A service to load the kernel module.
2. The mysensor_hal_service.
3. The data_processor_service.

Step 1: Kernel Module Loading Service

Instead of an on init block, we create a systemd service for loading the kernel module. This makes the module loading an explicit dependency.

# /etc/systemd/system/mysensor-driver-load.service[Unit]Description=Load MySensor Kernel ModuleDocumentation=https://example.com/docs/mysensorAfter=local-fs.target # Ensure local filesystems are mountedBefore=mysensor-hal.service # Explicitly order before the HAL service[Service]Type=oneshot # This service runs once to load the moduleExecStart=/usr/sbin/modprobe mysensor_driver # Or insmod if not in module pathStandardOutput=journal[Install]WantedBy=multi-user.target # Ensure it starts with the system

Step 2: MySensor HAL Service

Now, the HAL service can explicitly declare its dependency on the kernel module being loaded.

# /etc/systemd/system/mysensor-hal.service[Unit]Description=MySensor Hardware Abstraction Layer ServiceDocumentation=https://example.com/docs/mysensor-halRequires=mysensor-driver-load.service # Strict dependency: if driver fails, HAL won't startAfter=mysensor-driver-load.service # Ensures ordering: HAL starts only AFTER driver is loadedWants=network-online.target # So it can log/communicate if needed (soft dependency)After=network-online.target # Order after network[Service]Type=simple # Or 'forking' if it daemonizes by itselfExecStart=/vendor/bin/hw/[email protected]=systemGroup=systemEnvironment=PATH=/usr/local/bin:/usr/bin:/bin:/vendor/bin/hwRestart=on-failure # If the service crashes, systemd will try to restart itRestartSec=5s # Wait 5 seconds before restartingLimitNPROC=infinity # Allow unlimited processes for the service (useful for Android services)StandardOutput=journalStandardError=journalSyslogIdentifier=mysensor-hal[Install]WantedBy=multi-user.target

Step 3: Data Processor Service

This service will depend on the HAL service being active. We can use Requires and After to establish this relationship firmly.

# /etc/systemd/system/data-processor.service[Unit]Description=MySensor Data Processor ServiceDocumentation=https://example.com/docs/data-processorRequires=mysensor-hal.service # Data processor strictly requires the HAL to be runningAfter=mysensor-hal.service # Start data processor AFTER HAL is startedBindsTo=mysensor-hal.service # If mysensor-hal.service stops, this service also stops.Part=mysensor-services.target # A logical grouping for related services[Service]Type=simpleExecStart=/vendor/bin/data_processorUser=data_processorGroup=data_processor systemEnvironment=LD_LIBRARY_PATH=/vendor/lib64:/vendor/lib # Adjust as per Android's dynamic linker needsRestart=on-failureRestartSec=10sStandardOutput=journalStandardError=journalSyslogIdentifier=data-processor[Install]WantedBy=mysensor-services.target # This service is part of our custom target

Step 4: Creating a Custom Target (Optional, for Grouping)

For more complex scenarios, especially when managing multiple related services, a custom .target unit can group services logically and simplify management. The mysensor-services.target would ensure all related services are pulled in together.

# /etc/systemd/system/mysensor-services.target[Unit]Description=MySensor Related ServicesTargetRequires=mysensor-hal.service # If this target starts, it implies HAL must be runningAfter=mysensor-hal.service[Install]WantedBy=multi-user.target # This target starts with the system

Then, modify the [Install] section of mysensor-hal.service and data-processor.service to be `WantedBy=mysensor-services.target` instead of `multi-user.target`.

Key systemd Dependency Directives Explained

• Requires= (Strong Dependency): If the required unit fails to start or stops, this unit will also stop. Use for mission-critical dependencies.
• Wants= (Weak Dependency): The unit will attempt to start the wanted unit, but if the wanted unit fails or is not found, this unit will still proceed. Good for optional services.
• After= / Before= (Ordering): Specifies that this unit should start/stop after/before another unit. Does not imply a strong dependency; if the ‘after’ unit doesn’t start, the current unit might still attempt to start (unless combined with Requires= or Wants=).
• PartOf=: Links units such that starting/stopping a target unit will also affect units listed as PartOf it. This is useful for logical grouping without enforcing strict startup order.
• BindsTo=: A stronger version of Wants= combined with PartOf=. If the bound unit stops, this unit will also stop. If the bound unit fails to start, this unit will also fail.
• Conflicts=: Declares that this unit cannot run at the same time as another specified unit. If one starts, the other is stopped.

Managing and Debugging systemd Services

Once unit files are created, inform systemd about them and enable them:

sudo systemctl daemon-reload # Reload systemd manager configurationssudo systemctl enable mysensor-driver-load.service # Enable the driver loading service (or the target)sudo systemctl enable mysensor-hal.service sudo systemctl enable data-processor.service # If using individual WantedBy=multi-user.targetsudo systemctl enable mysensor-services.target # If using the custom target

To start, stop, or check status:

sudo systemctl start mysensor-services.target # Or individual servicesudo systemctl stop data-processor.service sudo systemctl status mysensor-hal.service # Check runtime status

For debugging, journalctl is indispensable:

journalctl -u mysensor-hal.service # View logs for a specific servicesudo journalctl -f # Follow all logs in real-time

Conclusion

Migrating complex Android services from init.rc to systemd involves a shift from an implicit, event-driven model to an explicit, declarative one. While initially demanding, leveraging systemd‘s powerful dependency management through directives like Requires=, After=, BindsTo=, and custom .target units provides unparalleled control and clarity over service interactions. This structured approach not only enhances reliability and maintainability but also standardizes service management, making custom Android-based embedded systems more robust and easier to integrate into broader Linux environments. Understanding and correctly applying these systemd features is crucial for a successful and stable migration.