[bandrami]

Because "Stop Job Running For User 1001: (22s / 90s)" with no indication of which @$%^ing stop job it is is incredibly annoying. And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. And nondeterministic service initialization is absolutely Broken and Wrong.

It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.

[PunchyHamster]

> And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time.

we had tens of thousands of init scripts where we fixed that exact problem with init scripts that were delivered with distro. It's not systemd problem and if anything systemd made it better.

> And nondeterministic service initialization is absolutely Broken and Wrong.

if your dependencies are wrong but init system works you were just lucky.

If you gonna complain, complain about no option to tell machine to shut down in a given time interval which means "my UPS got 5 minutes left pls turn off" is unsolvable under systemd unless you go thru every single unit file in distro and override their timeouts.

[bandrami]

I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.

[belorn]

In the old time with init scripts you had to figure out where to put all those sleep(10) based on the servers specific hardware and software stack. Far from everything in the initi script blocked execution until they completely finished, and things that previously worked could suddenly stop working if you changed hardware or software.

The big difference that created deterministic servers in the past is that you could install the server once and then leave it for 10+ years without doing any updates. People were proud of servers and services with massive uptimes with no patches and no reboots. I only see those now if they either have no internet connection or are locked down containers with very restricted network access.

[t43562]

Init scripts were horrible

Here's a dinit service file for starting my bluetooth daemon:

  type               = process
  command            = /usr/lib/dinit/dbus-wait-for -s -f 4 -n org.bluez /usr/lib/bluetooth/bluetoothd
  smooth-recovery    = true
  logfile            = /var/log/dinit/bluetoothd.log
  depends-on         = dbus
  depends-on         = local.target
  before             = login.target
  ready-notification = pipefd:4

This is about as complicated as it gets - ones I make myself might be 4 lines.

There's no dodgy bash script behind all of this - it's C++ that just works - I can stop start, list and reload services with reliability.

I love it.

[bandrami]

I still would love somebody to explain to me what's "dodgy" about a shell script that runs the commands you want run...

[belorn]

I mentioned it in the comment above. Commands that you run in a shell script do not always block execution until the underlying resources is fully available. If we take the network as an example, the script to open a vpn tunnel and providing the tap0 device may not be available for the next command to use just because you first run the network script, then start the vpn daemon, and then start the next daemon. What people did was to add a bunch of sleep(10) in hope that the tap0 was up by the end of the sleep, and this might had worked great for a few years until the admin added a few too many complex rules to the network daemon and now it need to be sleep(15) instead, but only on some days in the week. Everyone also knew (and ignored) that adding sleep in the initscript was a sign of bad design and extremely brittleness.

Debian did have a fairly good init builder that attempted to do some form of dependency ordering and trickery to get things done in the right order and in the right time, where you wrote a service-like configuration file and than rebuilt the initscript. The builder then compiled the configuration files into an generated shell script. Redhat did something similar if I recall right.

Manually editing the generated shell script was seen as both dodgy, brittle and dangerous given that it could be arbitrary changed by any installed package. Some packages also sed and awk directly at the generated init script.

[bandrami]

I'm curious about this world people seem to have lived in where inetd didn't exist.

[t43562]

e.g. Starting something in the background and having to stick sleep statements into the script to wait till it is ready to receive requests on whatever port it uses. The sleeps are fine on one machine and on another they aren't enough.

Stashing the PID somewhere and writing code to use the PID to work out if the process is still running and hasn't crashed so you can report a status on it. It's just a waste of one's own time doing this repeatedly and there are ways to do it badly. Every initscript repeated the work.

You could probably do something quite good with bash if you provided a library of functions and demanded that scripts be written to use them.

[bandrami]

Was I the only person that used inetd to bring up their services on demand? I could have sworn it was popular at the time.

[direwolf20]

I think it's the brittleness. Tomorrow your ethernet adapter is enp4s1 instead of enp3s0 (because of systemd) so your rc script doesn't set up networking and you have to fix it.

[bandrami]

Yeah devfs was better at that. A static dev tree was better still.

[direwolf20]

Device numbers are dynamically allocated. The main handle is the name. Network interfaces don't go in /dev anyway and are not files