Learning Artix Linux - OpenRC: Init & Service Management

#Introduction

Now we enter one of the most important parts: how services are managed. Episode 5 covers OpenRC, the most popular init system in the Artix ecosystem. OpenRC feels familiar because its style resembles the classic SysV init: simple shell scripts, runlevels, and dependency-based start ordering.

You'll learn the rc-update, rc-service, and rc-status commands, understand the structure of /etc/runlevels/ and /etc/conf.d/, and write your own service with dependencies. After this episode, you'll be able to manage services on an Artix-OpenRC system without confusion.

#OpenRC Core Concepts

#Runlevels and Services

OpenRC works with the concept of runlevels: groups of services that run together. The default runlevels are boot for early services, sysinit for the base system, default for everyday services, plus nonetwork, shutdown, and reboot for transitions. Services run via scripts in /etc/init.d/.

Service status can be seen with rc-status:

rc-status
rc-status default

The output of rc-status shows running and failed services per runlevel. If any service is labeled failed, that's the first place to look for problems.

#Core Commands: rc-update, rc-service, rc-status

#Enabling Services

Registering a service to run at boot is done with rc-update. The most common example: enabling networking in the default runlevel.

rc-update add dhcpcd default
rc-service dhcpcd start

rc-update add creates a symlink from the service script into the runlevel directory, while rc-service controls the running service. These two things are separate: one decides "enabled at boot," the other manages "current status."

#Managing Services at Runtime

For daily operations, this combination is used most often:

rc-service sshd start
rc-service sshd restart
rc-service sshd stop
rc-service sshd status

Remove a service from a runlevel with rc-update del. Check the start order with rc-update show, which displays all services across all runlevels at once.

#Configuration Directory Structure

#/etc/runlevels/ and /etc/init.d/

/etc/runlevels/ contains one subdirectory per runlevel with symlinks to scripts in /etc/init.d/. rc-update add is just a symlink creator; you can do the same thing manually:

ln -s /etc/init.d/sshd /etc/runlevels/default/sshd
ls -l /etc/runlevels/default/

Understanding this structure helps with troubleshooting: if a service doesn't start at boot, check whether its symlink exists in the right runlevel.

#/etc/conf.d/: Service Configuration Variables

Every OpenRC service can be configured via a file in /etc/conf.d/. Values here aren't executed, only sourced by the init script. Example for a daemon that needs arguments:

EXAMPLE_OPTS="--verbose --port 8080"

Read the /etc/conf.d/ file for every service you install, because configuration that looks "baked into the script" often lives here instead.

#Inter-Service Dependencies

#rc_need and rc_after

The start order between services is controlled by dependency variables in the init script. rc_need forces another service to start first, rc_use uses an existing service, and rc_after only adjusts ordering without requiring the other service to be up.

Example of a simple service script in /etc/init.d/:

#!/sbin/openrc-run
description="Example service with dependencies"
 
depend() {
    need net
    after firewall
}
 
start() {
    ebegin "Starting example service"
    start-stop-daemon --start --exec /usr/bin/example
    eend $?
}

The need net variable ensures networking is up before the service starts. The depend() structure is the heart of OpenRC's deterministic boot ordering.

#-openrc Service Packages

#Service Subpackages on Artix

Official services for major packages are provided via subpackages ending in -openrc. If you install nginx alone without the service subpackage, there's no init script for it:

sudo pacman -S nginx nginx-openrc
rc-update add nginx default

nginx-openrc provides /etc/init.d/nginx and the /etc/conf.d/nginx configuration. The same pattern applies to all service packages in the Artix repos.

#Verifying a New Service

After installing the subpackage, make sure the script is available and the service is healthy:

ls /etc/init.d/nginx
rc-update show | grep nginx
rc-service nginx start
rc-service nginx status

If rc-service nginx status shows status: started, your service is up. The combination of installing the subpackage, registering it in a runlevel, then starting it is the standard pattern you'll use repeatedly throughout this series.

#Logs and Troubleshooting

#Viewing Service Logs

OpenRC service logs are usually written by the daemon itself or via rc-log, a service that records init script output to /var/log/rc.log. Enable and view it:

rc-update add rc-log default
rc-service rc-log start
tail -f /var/log/rc.log

The output of tail -f /var/log/rc.log streams messages from services being started. For daemons like nginx, also read the application logs in /var/log/nginx/.

#When a Service Fails to Start

When a service fails, the diagnostic steps are: check the status, read the error message from rc-service <svc> start directly, then inspect the logs. Don't forget that a wrong configuration in /etc/conf.d/ is often the culprit:

rc-service sshd start --debug
rc-status

The --debug option on rc-service shows every step the script runs, including pulled dependencies. This is the fastest way to find out why a service won't start.

#Conclusion

Episode 5 equipped you to manage services on OpenRC: runlevels, rc-update for boot time, rc-service for runtime, the /etc/runlevels/ and /etc/conf.d/ structures, dependencies with rc_need, and the -openrc subpackages.

Key takeaways:

• OpenRC uses runlevels and scripts in /etc/init.d/.
• rc-update add registers a service into a runlevel for boot.
• rc-service controls the running service.
• /etc/conf.d/ stores each service's configuration variables.
• Dependencies are managed with need, use, and after.
• The -openrc subpackages provide official service scripts on Artix.

In the next episode, episode 6, we'll cover alternative inits: runit, s6, and dinit — a comparison of how they work, their service commands, and when to pick each one for different needs.