rc-update add sshd default registers SSH for the default runlevel. It does not start the SSH daemon. Conversely, rc-service sshd start can start the daemon immediately without enabling it for the next boot.

That separation is central to OpenRC. A service has a place in the boot configuration and a current runtime state, and those are different things. Confusing them can leave a service running until the next reboot but absent afterward, or registered to start at boot while still stopped today.

Runlevels describe which services belong to a system state

OpenRC organizes services into named runlevels. On a typical Linux installation, startup passes through sysinit, boot, and default. The first two handle early system initialization; default normally contains ordinary services selected by the administrator.

Membership is represented by symbolic links under /etc/runlevels/ that point to service scripts. For example, enabling sshd in the default runlevel creates a relationship conceptually like this:

/etc/runlevels/default/sshd
    -> /etc/init.d/sshd

The link expresses a boot-time selection. It is not the daemon process, and it does not indicate whether SSH is currently listening for connections.

OpenRC can also use custom runlevels and stacked runlevels. When it enters a runlevel, it calculates which services should run, including required dependencies. The OpenRC user guide documents this model and the conventional boot sequence.

Adding a service and starting it are separate operations

On a system where the sshd OpenRC service is installed, these commands configure future startup and activate it now:

rc-update add sshd default
rc-service sshd start

Their effects are independent. A service can be enabled but stopped; it can also be running without belonging to the default runlevel.

To inspect those two dimensions separately:

rc-update show
rc-status
rc-service sshd status

rc-update show reports runlevel membership. rc-status shows service states associated with active runlevels, while rc-service sshd status checks one named service.

Removing the boot-time registration likewise does not issue an immediate stop command:

rc-update delete sshd default
rc-service sshd stop

The first command removes membership from default; the second stops the running service. A later runlevel transition may independently stop services that no longer belong in the selected state, subject to dependency relationships.

This is similar to the distinction between systemctl enable and systemctl start, although OpenRC represents startup membership through runlevels and shell-based service scripts rather than systemd unit installation rules.

Dependencies can start a service that was never enabled

A runlevel is not a complete list of every service that will run. OpenRC builds a dependency graph from declarations in the service scripts, typically under /etc/init.d/.

Consider the dependency section of a hypothetical application service:

depend() {
    need localmount
    use net
    after bootmisc
}

Each declaration has a different operational effect:

  • need localmount is a hard dependency. OpenRC attempts to start it even when it has not been added to the current runlevel; the application must wait for it to succeed.
  • use net is a soft dependency. OpenRC attempts to use it when it is in the applicable runlevel, but the application does not require it.
  • after bootmisc expresses ordering if that service participates. It does not require OpenRC to start bootmisc merely to satisfy this relationship.

OpenRC also provides want for an optional dependency that it attempts to start even when the dependency is not in the runlevel. These distinctions matter more than the order in which services happen to appear in a directory.

For network-facing services, need net should not be added automatically. A daemon that listens on all interfaces may be able to start before an external interface is ready, while a hard dependency on net can prevent startup unnecessarily. The OpenRC service script guide explains both dependency semantics and this networking caveat.

OpenRC is not necessarily the PID 1 process

On many OpenRC systems, a separate init program such as SysVinit runs as PID 1 and invokes OpenRC during startup and runlevel changes. OpenRC computes the required service actions, executes them, and exits rather than remaining as a central resident manager.

There is also an optional openrc-init implementation that can act as PID 1 on Linux. Therefore, saying that OpenRC can never be PID 1 is incorrect. The two arrangements have different responsibilities even though they use OpenRC service and runlevel configuration. See the upstream init process guide.

OpenRC’s service state tracking should also not be confused with universal process supervision. A daemon that exits unexpectedly does not acquire an automatic restart guarantee merely because its service was added to a runlevel. Continuous supervision, if required, must be configured through an appropriate supervisor or service-specific mechanism.

When an enabled service does not appear to run

A useful diagnosis begins by checking whether the problem is configuration or execution.

If rc-update show lists sshd in default but rc-service sshd status reports it stopped, membership exists but the service is not active. Starting it explicitly can expose errors in its executable, configuration, permissions, or dependencies. If the daemon is running but absent from rc-update show, it may have been started manually or pulled in as another service’s dependency.

When comparing OpenRC with systemd, this distinction is more reliable than assuming that one is always lighter or faster. Boot time and memory consumption depend on the services selected, their dependencies, how they are launched, and whether separate supervision or logging components are installed.

The operational rule is precise: use rc-update to change which services a runlevel selects, rc-service to change a service’s state now, and the dependency declarations to explain why other services start or stop with it.

Linux OpenRC Runlevels Service Management