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