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.

> 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-...>

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.