Openrc-init and supervise-daemon

OpenRC has developed itself and has gained some new features. In this article two features are highlighted:


 * openrc-init, is OpenRC's own init system, and can act as a replacement for sysvinit, and
 * supervise-daemon, which can supervise daemon processes. Supervise-daemon could replace start-stop-daemon, which is used by quite a few services.

openrc-init
Replacing sysvinit with openrc-init takes a few steps. The description that follows refers to grub.


 * Pass  on the kernel's commandline. Update  as follows:
 * Regenerate :
 * Make sure agetty processes for tty1 to tty6 will be started under openrc-init:
 * Reboot your system:

Be aware that commands like, and are no longer working under openrc-init. Use, or instead.

supervise-daemon
OpenRC traditionally uses, often called s-s-d for starting, and stopping programs. When s-s-d starts a process it saves the process' PID somewhere on permanent storage (typically under ), and backgrounds (daemonizes) the process it started. When the time comes to stop, kill, or signal the daemon it uses the saved PID file to find the right process.

Supervising on the other hand usually keeps the started daemon as a child process of the supervisor. Backgrounding the daemon is therefore not needed, and not desired. An advantage of supervising a daemon is also that any terminal output sent to stdout and stderr can be caught by the supervisor, and sent to the system logger or to a file. Pidfiles are not needed because the supervisor process remembers the pid.

Bringing a service under supervision theoretically should be as easy as adding  to its conf file in. It turns out to be a little more complex in some cases.

OpenRC has the concept that services' startup code, the init files in can be adjusted through configuration files in. With this concept it is possible to add environment variables, or commandline options in the configuration file and not change the init file. Some init files however don't implement this concept fully and define variables in the init file that cannot be adjusted in the conf file. Examples are:

In such cases it might be needed to adjust the init file and not just the conf file.
 * defining a pidfile variable in an init file, e.g. in :
 * defining variables in the init file, rather then in the conf file, e.g. in :
 * not allowing for expansion of a variable, e.g. in :

Other cases that might need adjusting the init files are explicit references to the underlying utility s-s-d, which is not used in case of supervising.

The examples that follow for bringing a service under supervision all require that the a service is brought down prior to editing files in or.

agetty
agetty was already brought under supervise-daemon in the previous chapter.

Careful examination shows that there are still references to pidfiles. These pidfiles refer actually to the supervise-daemon process and not to the agetty daemons. To avoid confusion it is better to remove them. Comment the pidfile defintion out in to fix it:

acpid
Reviewing the man page of reveals:


 * .. will run as background process ..
 * .. -f, --foreground .. keeps acpid in the foreground by not forking at startup, and makes it log to stderr instead of syslog.

Edit as follows to make acpid run under supervise-daemon:

Start up the service:

Verify if acpid is now running under supervise-daemon:

Check the logs as well:

And when you create an acpid event, it will be logged:

Lastly, check if supervise-daemon will restart acpid when it terminates:

Notice the different PID.

avahi-daemon
contains a service avahi-daemon for service discovery. Its init file does not make use of s-s-d, but calls the binary  directly and gives it the instruction to daemonize:   on startup. This can be simply adjusted by defining the command variable as, and removing the start and stop functions from the file. Of course it is also needed to specify the supervisor.

Edit as follows:

Start the service back up:

Verify that the service is now supervised:

bluetooth
provides bluetooth services. The recipe to bring it under supervise-daemon is as follows:
 * remove the pidfile reference
 * remove the background instruction
 * define the supervisor

Edit as follows:

cupsd
Cups is the well known printing system of linux. Its daemon cupsd is provided by.

Remove the pidfile and s-s-d instructions from by commenting them out, and add the supervisor declaration to bring it under supervision:

dnsmasq
Dnsmasq, provided by package, is a lightweight DHCP and caching DNS server. Dnsmasq's init file contains references to s-s-d, and pidfiles. The daemon needs to be configured to run in foreground.

Edit as follows:

fcron
is a cron daemon implementation.

Edit as follows:

iwd
Iwd (iNet wireless daemon) is provided by and aims to replace. Remove the backgrounding instruction and define the supervisor to bring iwd under supervision:

Edit as follows:

ntpd
The network time protocol daemon ntpd, from package can be brought under supervision by editing the init file to:
 * remove the pidfile reference,
 * prevent forking to background by adding "-n" to the command line to of the ntpd daemon,
 * define the supervisor.

sshd
Sshd (Secure shell daemon) does not have a specific commandline option to run in foreground, instead it is needed to use the  debug option. There may be some more text logged.

Edit at the beginning of the file as follows:

All the way at the bottom of the file there is the reload function in which the s-s-d instruction should be changed to a supervise-daemon instruction:

syslog-ng
is an interesting case. Without any change, running syslog-ng under s-s-d it looks like this:

There is a process with in this case PID 7800 'supervising syslog-ng' with a parent-PID (PPID) of 1, which means its parent is the init process. There is also the process with PID 7802, which looks more like what we might expect, referencing the binary. This process' PPID is 7800, i.e. the supervising process.

The supervising syslog-ng process is actually also the same binary of syslog-ng:

Syslog-ng appears to be supervising itself. What it does after startup is:

If and when "supervise syslog-ng" detects that it's worker process (PID 7802) has terminated it will restart it. Syslog-ng calls this process mode "safe-background".
 * fork, to become a background daemon process (PID 7800) and get it to be adopted by the init process (PID 1);
 * fork again to create the worker process (PID 7802) as it's child process;
 * rename the process (PID 7800) to "supervise syslog-ng", in the parent process, and supervise its child (PID 7802).

In order to get syslog-ng to work well under supervise-daemon it needs to run in the foreground though. There are two commandline options that will make that happen  and.

With the standard init scripts syslog-ng writes a pid file. This interferes with the operation of supervise-daemon so will have to be removed. Edit to remove the --pidfile option in the command_args, and comment out the pidfile variable:

Services which won't run under a supervisor
Unfortunately not all services are easy to run under supervisor-daemon, or other supervisors. The requirement that the daemon needs to run in foreground is not satisfied with all daemons, or it simply does not work. Sometimes there are alternatives available.

dcron
version 4.5-r1 crashes without an error message when it is run under a supervisor. Consider an alternative like.

vixie-cron
Gentoo's has no option to run in foreground, even though in other Linux distributions the cron process would accept a -f flag. Consider an alternative like.

External resources

 * Mistakes to avoid when designing Unix dæmon programs
 * How to make daemons that will maximize sysadmin hatred