Managing System Services with OpenRC on Artix Linux

The Problem: Managing Services Without systemd

Many Linux distributions rely on systemd for service management, but Artix Linux provides an alternative for users who prefer a lightweight, script-based approach. The challenge for users transitioning to Artix is managing daemons—background processes like SSH, database engines, or networking tools—without the systemctl command. The takeaway is that OpenRC uses a decoupled approach: one tool manages the current state of a service, and another manages whether that service starts during the boot process.

Prerequisites

• An installed Artix Linux system configured with the OpenRC init system.
• Root or sudo privileges to modify system services.
• Basic familiarity with the Linux command line.

Controlling Services in Real-Time

To manage a service while the system is running, use the rc-service command. This command interacts with the scripts located in /etc/init.d/, which define how a specific piece of software should start and stop.

Common Service Operations:

# Start a service (e.g., the SSH daemon)
sudo rc-service sshd start

# Stop a service
sudo rc-service sshd stop

# Restart a service after configuration changes
sudo rc-service sshd restart

# Check if a service is currently running
rc-service sshd status

Risk Note: Running stop on critical services like networking or dbus may result in loss of connectivity or system instability until the service is restarted.

Configuring Boot-Time Persistence

Starting a service with rc-service is temporary; it will not survive a reboot. To ensure a service starts automatically, you must add it to a specific runlevel (a set of services that start at a particular stage of the boot process) using rc-update.

The most common runlevels in Artix are:

• boot: Essential services required to mount filesystems and initialize hardware.
• default: Standard services required for a functional user environment (e.g., networking, logging).
• shutdown: Scripts that run during the power-off sequence.

Example: Enabling SSH at Boot

# Add sshd to the default runlevel
sudo rc-update add sshd default

# Remove a service from the default runlevel
sudo rc-update del sshd default

Comparison: OpenRC vs. systemd Workflow

Verification and Diagnostics

To verify that your changes have taken effect and that the system is healthy, use the following diagnostic steps:

1. Check Global Status: Run rc-status. This displays all services currently running and those that failed to start in their assigned runlevels.
2. Verify Specific Daemon: Run rc-service [service_name] status to confirm the process is active.
3. Boot Test: Reboot the system using sudo reboot. Upon login, run rc-status again to ensure services added via rc-update initialized without errors.

Limitations and Recovery

Compatibility: Software that relies on systemd-specific APIs (such as certain proprietary VPN clients or complex systemd timers) will not work natively with OpenRC. In these cases, you must seek an OpenRC-compatible alternative or use a compatibility layer.

Rollback: If a service causes the system to hang during boot, boot into a live environment or single-user mode and remove the problematic service from the runlevel:

# Run this from a recovery shell to prevent the service from starting on next boot
rc-update del [problematic-service] default

Because runlevel changes directly affect boot behavior, always verify edits with rc-update show before rebooting to confirm which services are assigned to each runlevel.