Having the backing of RedHat certainly didn't hurt... I don't care either way, although I still think OpenRC style scripts are much easier to debug and sometimes have more elegant solutions (templates vs symbolic links).
Having the backing of RedHat certainly didn't hurt... I don't care either way, although I still think OpenRC style scripts are much easier to debug and sometimes have more elegant solutions (templates vs symbolic links).
I can't say I know what OpenRC really does, but at it's core systemd is just a glorified script runner as well? You have ExecCondition, ExecStartPre, ExecStart, ExecStartPost, ExecReload, ExecStop, ExecStopPost which are all quite self explanatory, this alongside a billion optional parameters which I wouldn't know how to implement in scripts without endless hours of dread.
I remember an old Debian machine with /etc/init.d/something [start|stop|reload|restart] but I can't recall being able to automatically restart services or monitor status easily. (I didn't speak $shell well back then either)
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):
'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:
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]:
[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.
> ...at it's core systemd is just a glorified script runner as well?
Yep. And it has a ton of accidental complexity in it. [0] At $DAYJOB, we ran into a production-down incident related to inscrutable SystemD failures once a year. It was always the case that the documentation indicated that our configuration and usage was A-OK. If there ever was a bug report filed, it was always the case that the SystemD maintainers either said words to the effect of "Despite the fact that the docs say that should work, that's an unsupported use case." or "Wow. Weird. Yeah, I guess that behavior is wrong, and it's true that the docs don't warn you about that.", and then go on to do nothing.
SystemD is -IME- like (again, IME) PulseAudio and NetworkManager... it's really great until you hit a show-stopping bug, and then you're just turbofucked because the folks who built and maintain it it want to treat it like it's a black box that works perfectly.
[0] NOTE: I am absolutely not opposed to complex things. I'm opposed to needlessly complex things, and very much opposed to things whose accidental complexity causes production issues, and the system's maintainers' reply to the bug report and minimal repro is "Wow, that's weird. I don't want to fix that. Maybe we should document that that doesn't work." and then go on to do absolutely nothing.
I use runit for some non-system-level stuff. It's extremely simple, possibly too simple. It doesn't manage load order - if a dependency hasn't loaded yet, you just exit the script and the service manager tries again in 2 seconds. Service scripts are just shell scripts.
There are two ways to design a system: so simple that it has obviously no bugs, and so complex that it has no obvious bugs.