SystemD Service Hardening

> systemd[-init] ALSO does not constantly change. The init system has been virtually untouched in a decade...

Sure, I'll bite. It'll be more interesting than watching some stupid Twitch streamer.

Gentoo Linux was using OpenRC back in 2002. Looking at the copyright notice in relevant source files, it looks like OpenRC is a project that has been under development since 1999, so I'd expect it was in use back in 1999. However, I will use 2002 as the start date for this discussion because that's when I started using it.

The simple OpenRC service file I mention in footnote 3 in [0] is syntactically identical to the syslogd service file added in to the OpenRC repo back in this commit in late 2007 [1]. The commit that appears to add support for 'command_args' and friends is earlier that day.

So, four years before SystemD's experimental release, the minimal OpenRC service file (that I talk about in [0]) was no more complicated than what would become the minimal SystemD service file no less than four years later. What's more, the more-verbose syntax for service files written in 2002 was supported by 2007's OpenRC, and continues to be supported by 2025's OpenRC.

23 years is quite a bit longer than 15.

> systemd is also not complex, it's remarkably simple. systemd unit files are flat, declarative config files.

See above (and below).

> Here, people get confused between systemd-init, and systemd the project.

In that case, it doesn't do you credit to use "systemd-init" and "systemd" interchangably in your commentary. SystemD absolutely has scope creep. systemd-init... well, I think I remember when it wasn't possible to have it rexecute itself for a no-reboot upgrade of PID 1. And does it still have a dependency on DBus, or did they see sense and get rid of that?

[0] <https://news.ycombinator.com/item?id=44945789>

[1] <https://github.com/OpenRC/openrc/commit/3ec2cc50261f37b76e0e...>

I've been reading through how many NixOS modules use systemd units and there's a lot of scripts being executed, the final line execs the service (if there is one, NixOS uses systemd for maintenance tasks, refreshing certificates and many more things). While NixOS doesn't speak for the broader community what I'm trying to say is that it can execute anything, if that's a script or a daemon doesn't matter as long as it works for you.

Thanks for the sysV explanation, it sounds worse to me.

> /etc/init.d/whatever were all shell scripts, and they all had to implement all the features themselves.

A minimal SystemD service file and a minimal OpenRC service file are equally complex.

Here's the OpenRC service file for ntpd (which is not a minimal service file, but is pretty close):

  #!/sbin/openrc-run
  
  description="ntpd - the network time protocol daemon"
  pidfile="/var/run/ntpd.pid"
  command="/usr/sbin/ntpd"
  command_args="${NTPD_OPTS}"
  command_args_background="-p ${pidfile}"
  command_args_foreground="-n"
  
  depend() {
   use net dns logger
   after ntp-client
  }
  
  start_pre() {
   if [ ! -f /etc/ntp.conf ] ; then
    eerror "Please create /etc/ntp.conf"
    return 1
   fi
   return 0
  }

'start_pre' is a sanity check that could be removed, or reduced to calling an external script (just like -IIRC- systemd forces you to do). There are _pre and _post hooks for both start and stop.

For a service that has no dependencies on other services, backgrounds itself, and creates a pidfile automatically, the smallest OpenRC service file is four non-blank lines: the '#!/sbin/openrc-run' shebang followed by lines declaring 'pidfile', 'command', and 'command_args'. A program that runs only in the foreground adds one more line, which tells OpenRC to handle daemonizing the thing and writing its pidfile: 'command_background="true"'. See [3] for an example of one such service file.

If you want service supervision, it's as simple as adding 'supervisor=supervise-daemon', and ensuring that your program starts in the foreground. If it doesn't foreground itself automatically, then adding 'command_args_foreground=<Program Foregrounding Args>' will do the trick.

If you're interested in more information about OpenRC service file syntax, check out the guide for them at [0], and for a lot more information, the manual for openrc-run at [1]. For supervision, check out the supervision guide at [2].

[0] <https://github.com/OpenRC/openrc/blob/master/service-script-...>

[1] <https://man.uex.se/8/openrc-run>

[2] <https://github.com/OpenRC/openrc/blob/master/supervise-daemo...>

[3] The OpenRC service file for the 'cups-browsed' service (which is a program that does not daemonize itself) is this:

  #!/sbin/openrc-run
  
  pidfile="/run/cups-browsed.pid"
  command="/usr/sbin/cups-browsed"
  command_background="true"
  
  depend() {
   need cupsd avahi-daemon
  }