4 ms·

That's a lie https://news.ycombinator.com/item?id=36513889#36514362 https://news.ycombinator.com/item?id=36513889#36514362 > In fact, much of my personal disl

by ilyt 3y ago

That's a lie https://news.ycombinator.com/item?id=36513889#36514362 https://news.ycombinator.com/item?id=36513889#36514362 > In fact, much of my personal dislike of systemd is that it started getting popular right as I was having that revelation and got to watch a pile of shell scripts that I could just pop open in my editor get replaced with an all-encompassing black box (yes, I know it's open source, but "you could go find the source and try to read C" is not the same as "vi /etc/init.d/foo". That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. For vast majority of apps it's literally just 'here is binary, run it' And more important part is that I DON'T NEED TO EDIT ORIGINAL if I just want to add something. I can take 100% stock distro .service file, add Restart=always RestartSec=60s and now any time app dies it will auto-restart. Or add proxy environment, or anything else, via just override files, no need to litter our repositories with modified init scripts that just have like 3 lines changed.

yjftsjthsd-h 3y ago
> That's a lie Oh, well now that you've called me a liar I suppose I have no choice but to agree with you. (/s) Here, let's have a worked example! https://git.alpinelinux.org/aports/tree/main/nginx/nginx.initd https://git.alpinelinux.org/aports/tree/main/nginx/nginx.ini... In that entire file, there is exactly one function that exceeds 3 lines; the "upgrade" command, which AFAIK doesn't exist in systemd-land. > That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. Partially true; I'll happily agree that 90% of daemons are the simple case. Of course, that's true regardless of the service manager in play; 90% of systemd service files are trivial, and 90% of initscripts are trivial. I'll also agree that there's an advantage to making the easy stuff common; if I were actually writing initscripts for a distro I'd have them start by including a library (probably `. /etc/init.d/_common.sh` or something like that) and then most of them would also just define the ~3 needed variables and use the default function implementations. And it would still be easier to follow than a compiled version.
- ilyt 3y ago
  But you aren't using bash! #!/sbin/openrc-run > openrc-run is basically an interpreter for shell scripts which provides an easy interface to the often complex system commands and daemons. When a service runs a command it first loads its multiplexed configuration file, then its master configuration file, then /etc/rc.conf and finally the script itself. At this point openrc-run then runs the command given. It essentially recreated "init script specific DSL" that systemd unit files are! So you don't have "conceptually simple" SysV script, you have massive wrapper that takes care of the ugly edge cases around starting and managing services and is also is entirely dependent on openrc stuff to work. And that's not even end of it! start-stop-daemon --signal QUIT --pidfile $pidfile.oldbin that's the wrapper Debian and other distros used a lot So you're using openrc wrapper to call shell that calls another wrapper. To run a service Systemd equivalent: [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed I rest my case
  - JdeBP 3y ago
    A unit file that wraps start-stop-daemon, has type=forking, and uses PID files. If it weren't a silly one-off on Hacker News, and if I hadn't already pointed out this foolishness years ago with exactly this service, it would be a prime candidate for the systemd House of Horror. * https://unix.stackexchange.com/a/504374/5132 https://unix.stackexchange.com/a/504374/5132 * https://jdebp.uk/FGA/systemd-house-of-horror/ https://jdebp.uk/FGA/systemd-house-of-horror/ openrc-run is itself merely a shell script, by the way.
    - ilyt 3y ago
      Yeah nginx one could just use systemd itself to send sigquit. I'm guessing either author didn't read up on all the options or the option to customize signal in systemd was added later

by ilyt 3y ago

yjftsjthsd-h 3y ago

> That's a lie Oh, well now that you've called me a liar I suppose I have no choice but to agree with you. (/s) Here, let's have a worked example! https://git.alpinelinux.org/aports/tree/main/nginx/nginx.initd https://git.alpinelinux.org/aports/tree/main/nginx/nginx.ini... In that entire file, there is exactly one function that exceeds 3 lines; the "upgrade" command, which AFAIK doesn't exist in systemd-land. > That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. Partially true; I'll happily agree that 90% of daemons are the simple case. Of course, that's true regardless of the service manager in play; 90% of systemd service files are trivial, and 90% of initscripts are trivial. I'll also agree that there's an advantage to making the easy stuff common; if I were actually writing initscripts for a distro I'd have them start by including a library (probably `. /etc/init.d/_common.sh` or something like that) and then most of them would also just define the ~3 needed variables and use the default function implementations. And it would still be easier to follow than a compiled version.

ilyt 3y ago
But you aren't using bash! #!/sbin/openrc-run > openrc-run is basically an interpreter for shell scripts which provides an easy interface to the often complex system commands and daemons. When a service runs a command it first loads its multiplexed configuration file, then its master configuration file, then /etc/rc.conf and finally the script itself. At this point openrc-run then runs the command given. It essentially recreated "init script specific DSL" that systemd unit files are! So you don't have "conceptually simple" SysV script, you have massive wrapper that takes care of the ugly edge cases around starting and managing services and is also is entirely dependent on openrc stuff to work. And that's not even end of it! start-stop-daemon --signal QUIT --pidfile $pidfile.oldbin that's the wrapper Debian and other distros used a lot So you're using openrc wrapper to call shell that calls another wrapper. To run a service Systemd equivalent: [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed I rest my case
- JdeBP 3y ago
  A unit file that wraps start-stop-daemon, has type=forking, and uses PID files. If it weren't a silly one-off on Hacker News, and if I hadn't already pointed out this foolishness years ago with exactly this service, it would be a prime candidate for the systemd House of Horror. * https://unix.stackexchange.com/a/504374/5132 https://unix.stackexchange.com/a/504374/5132 * https://jdebp.uk/FGA/systemd-house-of-horror/ https://jdebp.uk/FGA/systemd-house-of-horror/ openrc-run is itself merely a shell script, by the way.
  - ilyt 3y ago
    Yeah nginx one could just use systemd itself to send sigquit. I'm guessing either author didn't read up on all the options or the option to customize signal in systemd was added later