OpenRC Service Model

OpenRC Service Model is a framework designed to manage system services and daemons in Alpine Linux and other Unix-like operating systems using the OpenRC init system. It provides a structured methodology for defining, controlling, and supervising services throughout the system boot process and during runtime. The model emphasizes simplicity, portability, and flexibility while maintaining compatibility with traditional init scripts.

Core Concepts of the OpenRC Service Model

Service Definition and Scripts

At the heart of the OpenRC Service Model lies the concept of a service script, which is a shell script located typically in /etc/init.d/. Each service script encapsulates the logic needed to start, stop, restart, reload, and check the status of a particular service or daemon. These scripts follow a consistent interface, allowing OpenRC to interact with any service uniformly.

A service script must implement a minimum set of functions or commands such as:

• start: Initializes and launches the service.
• stop: Gracefully terminates the service.
• restart: Stops and then starts the service again.
• status: Reports whether the service is currently running.
• reload (optional): Reloads the configuration without restarting.

This uniformity enables OpenRC to manage all services transparently regardless of their internal implementation details.

Dependencies and Runlevels

OpenRC organizes services into runlevels, which are named collections of services grouped by system state or purpose, such as default, boot, nonetwork, shutdown, and others. Each runlevel corresponds to a set of services that should be started or stopped when entering or leaving that runlevel.

Services declare their dependencies explicitly within their service scripts or via dependency files. Dependencies are expressed in terms of:

• need: Services that must be started before the current service can start.
• use: Optional services that enhance functionality but are not mandatory.
• before and after: Ordering constraints relative to other services.
• provide: Virtual service names that a service can supply, allowing alternative implementations.

OpenRC resolves these dependencies to build a directed acyclic graph representing the correct startup and shutdown order, ensuring services start only after their needs are met and stop in an order that preserves system consistency.

Service Supervision and Monitoring

OpenRC supports service supervision to maintain service availability. It can respawn services that crash unexpectedly, although this feature is generally lightweight compared to more specialized supervisors like systemd or runit. The supervision model relies on the service scripts’ ability to check service status and restart them if necessary.

Configuration and Environment

Each service may have associated configuration files typically stored in /etc/conf.d/. These files define environment variables and options that modify service behavior without altering the service scripts themselves. This separation facilitates maintainability and customization.

OpenRC reads these configuration settings at runtime and passes them to the service scripts, allowing system administrators to tailor service parameters globally or per-instance.

Parallel Service Startup

OpenRC can start services in parallel whenever their dependency graph allows it, reducing system boot time. This concurrency is orchestrated by analyzing dependencies and ensuring no service runs before its dependencies are ready.

Integration with the Init System

OpenRC acts as a replacement for traditional SysV init, managing the overall system initialization and shutdown process. Upon boot, OpenRC initializes essential services in the boot runlevel, transitions to the default runlevel for normal operation, and eventually moves to the shutdown runlevel during system halt or reboot.

This integration ensures a predictable and controlled environment for service management, with clear stages and defined behaviors.

Structure and Components

Usage and Management

OpenRC provides a set of command-line tools to interact with the service model:

• rc-service <service> start|stop|restart|status|reload: Controls individual services.
• rc-update add <service> <runlevel>: Adds a service to a specific runlevel.
• rc-update del <service> <runlevel>: Removes a service from a runlevel.
• rc-status: Lists running services and their status within runlevels.

These commands enable administrators to manage system services dynamically, reflecting changes immediately or persisting them across reboots by modifying runlevel configurations.

Advantages of the OpenRC Service Model

• Simplicity: Uses plain shell scripts and avoids complex binary daemons.
• Portability: Works on various Unix-like systems beyond Alpine Linux.
• Transparency: Service management is explicit and easy to understand.
• Flexibility: Supports fine-grained dependency management and customization.
• Speed: Enables parallel startup to reduce boot times.
• Modularity: Separates configuration from code, easing maintenance.

Illustrative Example of a Service Script Skeleton

#!/sbin/openrc-run

command="/usr/sbin/mydaemon"
command_args="--option"
pidfile="/var/run/mydaemon.pid"

depend() {
    need net
    use logger dns
    before apache2
}

start() {
    ebegin "Starting mydaemon"
    start-stop-daemon --start --pidfile "$pidfile" --exec "$command" -- $command_args
    eend $?
}

stop() {
    ebegin "Stopping mydaemon"
    start-stop-daemon --stop --pidfile "$pidfile"
    eend $?
}

This example demonstrates how a service script specifies dependencies, commands, and the start/stop logic, conforming to OpenRC's expectations.

Summary of the OpenRC Service Model’s Role

The OpenRC Service Model standardizes service management by defining a consistent interface for starting, stopping, and supervising system services. It organizes these services into logical groups and orders their execution based on explicit dependencies. By doing so, it provides a robust and maintainable framework that balances simplicity with powerful features, suited to Alpine Linux and similar environments where full systemd replacements are desired.