4 ms·

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 sometime

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

lillecarl 1y ago
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)
- dale_glass 1y ago
  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.
  - lillecarl 1y ago
    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.
  - simoncion 1y ago
    > /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-guide.md#openrc-service-script-writing-guide https://github.com/OpenRC/openrc/blob/master/service-script-...> [1] <https://man.uex.se/8/openrc-run https://man.uex.se/8/openrc-run> [2] <https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md 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 1y ago
- simoncion 1y ago
  > ...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.
immibis 1y ago
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.

lillecarl 1y ago

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)

dale_glass 1y ago
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.
- lillecarl 1y ago
  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.
- simoncion 1y ago
  > /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-guide.md#openrc-service-script-writing-guide https://github.com/OpenRC/openrc/blob/master/service-script-...> [1] <https://man.uex.se/8/openrc-run https://man.uex.se/8/openrc-run> [2] <https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md 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 1y ago
simoncion 1y ago
> ...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.

immibis 1y ago

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.