4 ms·

Init scripts were horrible Here's a dinit service file for starting my bluetooth daemon: type = process command = /usr/lib/dinit/

• bandrami 9mo ago
  I still would love somebody to explain to me what's "dodgy" about a shell script that runs the commands you want run...
  • direwolf20 9mo ago
    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 9mo ago
      Yeah devfs was better at that. A static dev tree was better still.
      • direwolf20 9mo ago
        Device numbers are dynamically allocated. The main handle is the name. Network interfaces don't go in /dev anyway and are not files
        • bandrami 9mo ago
          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.
          • bandrami 9mo ago
            (Sorry, pre-sysfs. Though chronologically also pre-devfs)
          • direwolf20 9mo ago
            Network interfaces always had names sequentially assigned by the kernel. systemd overrides them based on PCIe bus location, which changes when you install new hardware. Lennart insists that PCIe bus locations don't change when you install hardware, even though this is obviously wrong as proven by real–world evidence.
  • belorn 9mo ago
    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 9mo ago
      I'm curious about this world people seem to have lived in where inetd didn't exist.
  • t43562 9mo ago
    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 9mo ago
      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.