> /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
  }

'depend' handles service dependency declaration and start/stop ordering (obviously).

'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
  }

▲ dale_glass 6 days ago | parent [-]

So on one hand, yes, that's a vast improvement over SysV.

On the other hand, no sir, I still don't like it. It looks very much like Bash. I'm not very fond of Bash to start with and it might not even be actual Bash? Can't tell from the manpage.

But scrolling down to the bottom of the manpage I see a pretty long sample script, and that's exactly what I want to see completely gone. I don't want to look at a 3-way way merge of a service during an upgrade ever again and try and figure out what's all that jank doing. IMO if any of that shell scripting has any reason to be in a service file, it's a bug to be fixed.

My ideal is the simple systemd services: description, dependencies, one command to start, done. No jank with cleaning up temp files, or signals, or pid files (can they please die already), or any of that.

And one of the nice things about systemd services not being a script is that overrides are straightforward and there's never any diffs involved.

▲ simoncion 6 days ago | parent [-]

> My ideal is the simple systemd services: description, dependencies, one command to start, done.

> ...

> But scrolling down to the bottom of the manpage I see a pretty long sample script, and that's exactly what I want to see completely gone.

First: I know that you read my comment. The two OpenRC service files that I embedded in it are typical service files. The one in the man page serves as a feature demo, as is appropriate for a man page. [0]

Second: necessary complexity has to live somewhere. Complex OpenRC service files are complex nearly always because the work that their author is doing needs to get done. As folks observe, SystemD service files often are used to invoke a bunch of scripts. As I have demonstrated, you can choose to write OpenRC service files in exactly the same style as you'd use to write a SystemD service file. [1] But if you choose to write OpenRC service files in only that style, and if you need to do complex things as part of service lifecycle management, then you'll need to do what SystemD forces you to do and push that logic out to separate scripts/programs.

Necessary complexity has to live somewhere.

> I don't want to look at a 3-way way merge of a service during an upgrade ever again and try and figure out what's all that jank doing.

I've been using Gentoo Linux for twenty-three years. In the handful of times I've had to examine a service file update, the changes to it have never not been straightforward.

> ...it might not even be actual Bash? Can't tell from the manpage.

It's sh, handled by openrc-run. I'll quote from the service-script-guide that I linked to previously. See [2]:

  Service scripts are shell scripts. OpenRC aims at using only the standardized
  POSIX sh subset for portability reasons. The default interpreter (build-time
  toggle) is /bin/sh, so using for example mksh is not a problem.
  
  OpenRC has been tested with busybox's sh, ash, dash, bash, mksh, zsh and
  possibly others. Using busybox's sh has been difficult as it replaces
  commands with builtins that don't offer the expected features.
  
  The interpreter for service scripts is #!/sbin/openrc-run. Not using this
  interpreter will break the use of dependencies and is not supported.

[0] You noticed that the commands added to the service file are named "eat" and "drink"? If nothing else indicated to you that this was a feature demo, that should have.

[1] It's a lot less work to write them in this "key, value" style, and it's obviously good to do so whenever reasonably possible.

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

	▲	simoncion 6 days ago \| parent [-]
		Also, from what I can tell, OpenRC's 'supervise-daemon' resolves the problem folks claim to have with PID files. [0] While the PID file is still needed, the contents of that PID file is the PID of the supervise-daemon instance that's monitoring the service. You might quite reasonably ask "What happens when supervise-daemon crashes or is OOM killed?". I would reply "I'd imagine the same thing that happens when 'systemd' crashes or is OOM killed, except with a far smaller circle of devastation.". I'd also expect supervise-daemon to be no less reliable than 'systemd'. [0] I would also expect most service supervision systems to solve this problem. OpenRC has supported using s6 as a supervisor for a long time, and OpenRC's supervise-daemon is relatively new, seeing as how it was introduced in 2016. My comments are about supervise-daemon because that's the only one that I've bothered to use.