Hacker News Reader

Comment by ape4 | Hacker News Reader

1. You don't have to clone then modify a 100 line bash script for a normal daemon's /etc/rc.d/init.d script.

The OpenBSD init system and OpenRC init system haven't had this problem for years -- even before systemd became a thing.

Similarly runit, s6, and Upstart have never had that issue. It is the oddest complaint to come up with when considering life without systemd.

Upstart was good and probably paved the way to systemd.

I wonder if systemd is influencing a new init right now

No, Upstart’s design was so bad that even Scott James Remnant (the creator of Upstart) admitted it’s design was inherently flawed.

The biggest problem with Upstart was that it put the dependency chain upside down and just started a service whenever it’s dependencies were fulfilled, no matter whether it actually made sense to start the service.

I remember reading about it and thought it seemed wrong, but presumably the author did his research and knew what he was doing. Oh well. His attitude and the readability of Upstart code were very good, though.

The Upstart design was probably easier to implement. With the systemd design, the dependency tree needs to be traversed bottom up (figure out what needs to be started to start the targeted set of services), then top down (start dependees when dependencies are ready). With Upstart, top down was enough. Or so it seems.

Do you have a source on SJR stating that the event based design was inherently flawed?

I think the comments towards the bottom of this thread is what is being referred to: https://web.archive.org/web/20140928104327if_/https://plus.g...

I for one have great sympathy for people who are placed in the position of having to give good reasons for using systemd. "All your distro are belong to us" was the original plan but it didn't quite work out. The shills had to scramble but they managed to make the best of a bad situation.

OpenRC is the only init system I've ever used on Linux that I actually like, rather than just tolerating.

This

I've not seen even sysvinit based systems with this problem. Every service manager I know of solves this problem. This is as much an argument in favour of systemd as "don't have to clean up horse excrement" is an argument in favour of owning a fiat 500.

Most init scripts are in that ballpark. See openssh for example (88 lines) https://github.com/openssh/openssh-portable/blob/master/open...

And yet, it still tries to use pidfiles (which systemd has a better alternative for), and notes "We really should check if the service is already going" which they don't do because it's an actual non-trivial issue if you're writing a standalone init script.

Does anyone use these init scripts? Every popular sysvinit based init system uses short declarative service scripts for most services. Every non-sysvinit init system seems to mostly manage with 2 line scripts.

And yes pidfiles are crap and I don't like them either (a genuine criticism of sysvinit and advantage of systemd) but systemd isn't the first init system to do away with pidfiles so it's hardly a unique strength.

Could you show an example of a declarative sysv-init script? To be honest, I'm not aware of it being possible and ddg doesn't bring up anything.

> Does anyone use these init scripts?

By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them)

This is OpenBSD's sshd init script:

https://github.com/openbsd/src/blob/master/etc/rc.d/sshd

On an archlinux system running systemd I see that the equivalent of the rc_reload function is "ExecReload=/bin/kill -HUP $MAINPID" (which is actually less safe...)

I'm not sure if you think that's declarative but to me it's basically as declarative as you can make a shell script.

> By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them)

I mean is anyone CURRENTLY using them? Because as far as I'm aware the linux sysvinit situation was a gigantic mess which nobody wanted to bother fixing despite the fact that OpenBSD and other BSDs had already fixed it by that point.

I think most linux distros can be taken as an example of how not to do things if you want to make your life easier.

Nowadays BSDs don't use these awful scripts. OpenRC based systems don't use these awful scripts. Who is using them?

> This is OpenBSD's sshd init script:

It's highly abstracted with macros, but that's not the same as declarative. It's still using full shell evaluation and any service can complicate it or make it slightly different. It's pretty close though.

> I see that the equivalent of the rc_reload function is "ExecReload=/bin/kill -HUP $MAINPID" (which is actually less safe...)

> man: "rc_reload - Send a SIGHUP signal using pkill(1) on the regular expression given in the pexp variable."

I don't understand why it would be less safe. $MAINPID is well defined because systemd knows the top process in that service's group. A pkill/regex by definition matches by text, so it can HUP any process with matching name - whether it was started by this service or not.

> I mean is anyone CURRENTLY using them?

Not that I'm aware of. They're still installed for people who don't have a different supported init system, but that's just edge cases these days.

It's less safe because it reloads sshd regardless of if the reload would cause sshd to fail to reload. It runs a config check of sshd before it goes ahead and asks sshd to reload its config.

That's an openssh issue though - nothing to do with the init system. You can do the same check regardless.

I put it in parentheses for a reason...

> By default every popular distro before systemd/upstart did

RedHat and friends, Debian all used convoluted init scripts which somewhat validates the need for systemd.

> By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them)

Honestly I wouldn't be surprised if much of the negativity surrounding systemd (other than people who don't like the architectural approach) is from not being able to use a clean startup configuration, instead having to use a bolted-together compilation of startup methods under the systemd "brand".

It's been a while since I've confirmed this with a new install, but while my Arch Linux setup is very clean, Ubuntu has always been a mess. It still has compatibility with the old "service" command (from Upstart I think?) for goodness sake. My Ubuntu install still has a ton of scripts running under the systemd shim, while as far as I can tell everything that is running on Arch has a .service file. If you're going to appreciate the value of systemd, the latter is a much better experience.

I have 90 scripts in my /etc/init.d directory. 51 are less than 100 lines, the most recent one I created is actually a perl script which is 29 lines long.

Yeah, with the #!-lines, sysv init scripts can be written in just about anything and, as long as you implement the expected command line interface, the init system will handle it correctly.

Hmmm, I wonder if anyone has made program for this purpose that will read the rest of the file a declarative definition of a service? Like imagine a SYSTEMd unit file with a shebang at the top .

Instead you have to write a couple-hundred-line bash script and then modify an under-documented ini-file to reference it

you never used systemd?

There's a bit of truth in that. The file format is underdocumented. You've got to look everywhere to find snippets of information, and then there are these weird incompatibilities between versions (Service.Type bit me once, and either After or Wants simply didn't do what the scant information suggested). And it often starts a script or a dedicated tool, e.g. for backing up, or watching directories.

However, it's easier to deploy and keep track of your own services, sudo and chdir are built in, there's a watch dog, easy journaling. That's nothing to sneeze at.

I’ve written a handful of systemd units now and, while the simple cases are nice, anything more complicated is really hard to figure out by reading manpages or other official sources of documentation. And, additionally, I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself.

As far as the watchdog but things go there’s plenty of good enough solutions that don’t really on systemd: daemonize, DJB’s daemontools, etc.

I've written many systemd services, and other units. Some of which were quite complicated. I found the man pages extremely useful. Moreso than the manpages for sysvinit or upstart, when I used those systems.

> I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself.

But that’s a completely fine solution, service files are not meant for declaring arbitrary logic.

Reply on news.ycombinator.com