Hacker News Reader

Comment by op00to | Hacker News Reader

… you’re mourning SysV init scripts? why?

I mourn it. I've been typing '/etc/init.d/apache2 restart' for about twenty years now. Why change it?

Would it really be that hard to have a symlink from /etc/init.d/apache2 to /bin/systemctl and teach systemctl to do the right thing?

There's a generic wrapper which existed for many years "service apache2 restart" will work regardless of the init type.

You can also put "systemctl $1 apache2" in /etc/init.d/apache2 and keep using it. It's really not a big issue.

Be the change you want to see.

If nothing else, sysv scripts were conceptually really simple to the point that you look at it and think "oh, it's just a shell script; I could actually just sit down and reimplement the whole system in a weekend". 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's a lie

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.

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

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

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://jdebp.uk/FGA/systemd-house-of-horror/

openrc-run is itself merely a shell script, by the way.

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

Because it will one day be “invented” again as a “scriptable init”

Reply on news.ycombinator.com