[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

[bandrami]

This was almost 30 years ago so my memory is fading, but pre-devfs when they were just in the /proc tree you could tell the kernel to bring them up in a given order and so assign the name you wanted to a given card.