Learning Devuan GNU/Linux - sysvinit: Init & Service Management

#Introduction

This is the most characteristically Devuan episode: sysvinit. Unlike systemd, which manages services through unit files, sysvinit works with runlevels, shell scripts, and symlinks. Episode 5 explains how PID 1 works, the /etc/inittab file, the /etc/rcN.d/ directories, and the scripts in /etc/init.d/, then practices the service management commands.

Mastering sysvinit isn't just nostalgia — it's the ability to read a transparent system. Every service is a script you can read in full, every runlevel is a directory you can inspect. You know exactly what happens at boot, what's running, and why.

By the end of this episode, you'll be able to manage Devuan services day to day: starting, stopping, restarting, checking status, setting auto-start, and switching runlevels without any help from systemd.

#How sysvinit Works

#From PID 1 to Runlevels

When the kernel finishes booting, it runs init as PID 1. init reads /etc/inittab to determine the default runlevel, then executes the scripts in that runlevel's directory. Runlevels are the system's operating modes: 0 for shutdown, 1 for single-user, 2 through 5 for multi-user, and 6 for reboot.

Each runlevel N has a /etc/rcN.d/ directory containing symlinks to the scripts in /etc/init.d/:

/etc/rc2.d/
  S01rsyslog -> ../init.d/rsyslog
  S02cron   -> ../init.d/cron
  S03ssh    -> ../init.d/ssh
  K01alsa   -> ../init.d/alsa

Symlinks with the S (start) prefix are run with the start argument when entering a runlevel; the K (kill) prefix is invoked when leaving the runlevel. The two-digit number determines the execution order — the smaller the number, the earlier it runs.

#Runlevels in Devuan

Devuan follows the Debian convention: runlevel 2 is the default multi-user, and 3, 4, 5 are also multi-user with no meaning difference unless specially configured. Runlevel 1 is single-user mode for maintenance, 0 for shutdown, and 6 for reboot.

Verify the default runlevel on your system:

grep ^id: /etc/inittab

The output of grep ^id: /etc/inittab shows id:2:initdefault: on a standard Devuan system. If you change it to 1, the system will boot straight into single-user mode.

#Scripts in /etc/init.d/

Init scripts are shell programs that accept arguments like start, stop, restart, and status. Read one to understand the pattern:

head -20 /etc/init.d/ssh

Most scripts use the /lib/lsb/init-functions library for consistent logging. Because they're plain text, you can inspect and modify them directly — this transparency is the essence of the Devuan philosophy.

#Managing Services with sysvinit

#The service Command

The service command is the easiest way to interact with a single service:

sudo service ssh status
sudo service ssh start
sudo service ssh restart
sudo service ssh stop

service ssh status shows the status and PID of the process if it's running. For a list of all known services, type service --status-all — each service is marked [ + ], [ - ], or [ ? ].

#Setting Auto-Start with update-rc.d

To control which services start at boot, use update-rc.d (or sysv-rc):

sudo update-rc.d ssh enable
sudo update-rc.d ssh disable

update-rc.d ssh enable creates symlinks in the appropriate runlevels; disable removes them. If you want full control over ordering, sysv-rc-conf provides an interactive ncurses interface for checking services per runlevel.

#Runlevels and telinit

#Switching Runlevels

The runlevel command shows the previous and current runlevel, while telinit changes the runlevel while running:

runlevel
sudo telinit 1
runlevel

runlevel shows e.g. N 2 — no previous runlevel, currently 2. The command sudo telinit 1 moves the system to single-user mode for repairs. To return, run sudo telinit 2.

#Reading the Running State

If a service doesn't show up in service --status-all, check whether its init script exists and has the execute bit:

ls -l /etc/init.d/nginx
test -x /etc/init.d/nginx && echo "executable"

The test -x /etc/init.d/nginx pattern is a quick trick to verify whether an init script is ready to run. If it isn't executable, fix it with sudo chmod +x /etc/init.d/nginx. This trick is very useful when writing your own init scripts for applications.

#Writing a Simple Init Script

To complete the understanding, let's write a minimal init script:

cat > /etc/init.d/myapp <<'EOF'
#!/bin/sh
case "$1" in
  start) echo "starting myapp";;
  stop)  echo "stopping myapp";;
  restart) $0 stop; $0 start;;
  *) echo "Usage: $0 {start|stop|restart}"; exit 1;;
esac
EOF
sudo chmod +x /etc/init.d/myapp
sudo service myapp start

The script above accepts start, stop, and restart arguments like professional init scripts. In production practice, you'll add PID checks and logging functions — but the basic structure is exactly like this.

#Conclusion

Episode 5 explained sysvinit as Devuan's default init: PID 1 reads /etc/inittab, runs runlevels in /etc/rcN.d/, and invokes scripts in /etc/init.d/. You also learned to manage services with service, set auto-start with update-rc.d, and switch runlevels with runlevel and telinit.

Key takeaways:

• sysvinit is PID 1 and Devuan's default init.
• Runlevels determine which services run.
• Service scripts live in /etc/init.d/; symlinks in /etc/rcN.d/.
• The S prefix means start when entering a runlevel, K means kill when leaving.
• service manages a single service; update-rc.d sets auto-start.
• runlevel and telinit read and change the active runlevel.

In the next episode, we'll cover alternative inits: OpenRC and runit — managing services with rc-service and rc-update, understanding /etc/conf.d/, then using sv and runsvdir for runit, and when to choose each init.