systemd tries to avoid scripts as much as possible.

/etc/init.d/whatever were all shell scripts, and they all had to implement all the features themselves. So `/etc/init.d/foo restart` wasn't guaranteed to work for every script, because "restart" is something that each script handled individually. And maybe this one just didn't bother implementing it.

There's no good status monitoring in sysV because it's all convenience wrappers, not a coherent system.

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
  }