Introduction / Why This Is Needed
Although systemd has become the de facto standard for most Linux distributions, there are popular and stable alternatives such as SysVinit, OpenRC, and runit. This guide will help you master service management in such environments. You will learn how to start, stop, enable at boot, and create custom scripts for managing services, which is particularly relevant for Alpine Linux, Gentoo, Void Linux, and specialized Debian/Ubuntu builds without systemd.
Requirements / Preparation
- Access to a Linux terminal with sudo privileges (or root).
- Basic understanding of the command line and the
/etc/directory structure. - A text editor installed (
nano,vim). - Knowledge of which init system your distribution uses (see Step 1).
Step 1: Identify the Current Init System
Before starting, you need to understand which init system manages processes on your system. This is a crucial step, as commands for SysVinit and OpenRC differ.
Execute the following commands:
# Method 1: Check which process has PID 1 (this is the init system)
ps -p 1 -o comm=
# Method 2: Check the type of symbolic link /sbin/init
ls -l /sbin/init
# Method 3: For OpenRC, often there is a file /etc/openrc/conf.d
# or the presence of the /etc/runlevels/ directory
ls /etc/runlevels/ 2>/dev/null && echo "Possibly OpenRC"
Expected Results:
initorsysvinit→ SysVinit is in use.openrcorrunit→ OpenRC or runit is in use, respectively.systemd→ You have systemd, and this guide does not apply.
Step 2: Managing Services in SysVinit
SysVinit is the classic system that uses scripts in /etc/init.d/ and management via service and chkconfig (or update-rc.d in the Debian family).
2.1. Basic Service Operations
# Start a service (example for nginx)
sudo service nginx start
# Stop a service
sudo service nginx stop
# Restart
sudo service nginx restart
# Check status (in some systems)
sudo service nginx status
# Force configuration reload (if supported)
sudo service nginx reload
2.2. Managing Autostart
In SysVinit, autostart is managed through symbolic links in runlevel directories (/etc/rc.d/rc?.d/ or /etc/rc?.d/).
For Red Hat, CentOS, Fedora (uses chkconfig):
# Add service to autostart for runlevels 2,3,4,5
sudo chkconfig nginx on
# Remove from autostart
sudo chkconfig nginx off
# View which runlevels the service is enabled for
sudo chkconfig --list nginx
For Debian, Ubuntu (uses update-rc.d):
# Add to autostart (default for runlevels 2,3,4,5)
sudo update-rc.d nginx defaults
# Remove from autostart
sudo update-rc.d -f nginx remove
# Explicitly specify runlevels (e.g., 2,3,4,5)
sudo update-rc.d nginx start 20 2 3 4 5 . stop 80 0 1 6 .
Step 3: Managing Services in OpenRC
OpenRC is a runlevel-dependent system popular in Alpine Linux and Gentoo. The main commands are rc-service and rc-update.
3.1. Basic Service Operations
# Start a service
sudo rc-service nginx start
# Stop
sudo rc-service nginx stop
# Restart
sudo rc-service nginx restart
# Check status
sudo rc-service nginx status
# Get a list of all services and their status
rc-status --all
3.2. Managing Autostart (Runlevel)
In OpenRC, services are added to a runlevel (boot level), such as default (analogous to multi-user.target) or nonetwork.
# Add service to the 'default' runlevel (autostart on normal boot)
sudo rc-update add nginx default
# Remove service from runlevel
sudo rc-update del nginx default
# View which services are added to the 'default' runlevel
rc-update show default
# List all available runlevels
rc-update -v
Step 4: Creating and Configuring a Custom Init Script
Sometimes you need to create a script for your own application. An example for SysVinit (the logic for OpenRC is very similar, but there are nuances in the script header).
- Create the script file in
/etc/init.d/:sudo nano /etc/init.d/myapp - Add the following content (adapt for your application):
#!/sbin/runscript # Copyright (c) 2026 FixPedia Team # Service name description="My custom service" # Start command (path to binary or script) command="/usr/local/bin/myapp" # Command options command_args="--config /etc/myapp/config.conf" # User to run as (optional) # user="myuser" # PID file (if the application writes its own PID) # pidfile="/run/myapp.pid" depend() { # Specify dependencies, e.g., on network or a directory # need net # use dns } start() { ebegin "Starting MyApp" start-stop-daemon --start --exec $command -- $command_args eend $? } stop() { ebegin "Stopping MyApp" start-stop-daemon --stop --exec $command --retry=TERM/30/KILL/5 eend $? }
For OpenRC, the script also starts with#!/sbin/runscript, but thestart()/stop()functions are written withoutstart-stop-daemon, using a direct call to$command. Seeman openrc-runfor details. - Make the script executable:
sudo chmod +x /etc/init.d/myapp - For SysVinit: add it to autostart (see Step 2.2). For OpenRC: add it to a runlevel (see Step 3.2).
Step 5: Checking Status and Logs
After configuring a service, it's important to ensure it's running correctly.
# For SysVinit
sudo service myapp status
# Or check the process
ps aux | grep myapp
# For OpenRC
sudo rc-service myapp status
rc-status
# View logs (depends on syslog configuration)
sudo tail -f /var/log/syslog
# Or /var/log/messages, /var/log/daemon.log
# If systemd-journald is used as a logger (possible in hybrid systems)
sudo journalctl -u myapp -f
Common Issues
- "Permission denied" error when running the script: Ensure the script in
/etc/init.d/is executable (chmod +x). Check permissions on the service's executable file. - Service not adding to autostart: In SysVinit, check for symbolic links in
/etc/rc?.d/. In OpenRC, ensure the service is added to the correct runlevel (rc-update show). - Service starts but immediately crashes: Check the logs (see Step 5). Common causes: incorrect path to the binary, missing configuration file, insufficient permissions (try
user=in an OpenRC script orstart-stop-daemon --chuid). - Service dependencies: If your service requires a network or database, be sure to specify dependencies in the script (
depend()in OpenRC or# Required-Start:comments in SysVinit). This prevents race conditions during startup. - Service does not respond to
stop: Thestopscript might not handle signals correctly. Usestart-stop-daemon --stop --retry=TERM/30/KILL/5for a graceful shutdown.