5 ms·

There’s nothing particularly cumbersome about init scripts. On a system where the primary API is the shell, initialising everything with a sequence of imperati

There’s nothing particularly cumbersome about init scripts. On a system where the primary API is the shell, initialising everything with a sequence of imperative shell commands makes a lot of sense.

ungamedplayer 6y ago
Casual admins made race conditions and other security bugs in init scripts.
- welterde 6y ago
  For me systemd created more race-conditions than it fixed (especially if the old init system started things serially). Getting it right in serial fashion is fairly easy, but since systemd insists on doing as much as possible in parallel you really need to have every dependency correctly configured (which is not always that easy to get right if things take a couple of seconds to get going..).
  - kaba0 6y ago
    What? You have to specify a dependency in the .service file, what does it matter how much time does any of them take? That’s the whole purpose of dependency management. Either that is missing or you have some other config error, like the service believing it is ready, because it is not told about its state correctly? But there is a setting to fall back to serial mode I believe, but it will also not work correctly if your service files are configured incorrectly.
    - welterde 6y ago
      Exactly my point. You have to configure all dependencies correctly as well as have all the dependencies themselves configured correctly to make systemd aware at what point they are ready (which again can be non-trivial to do). It is much less forgiving to mistakes (and yes.. the little annoyance I am having right now has the dependencies set correctly, correct service type, systemd-analyze chain looks good.. so mistake is somewhat well hidden).
      - hnarn 6y ago
        What exactly is your point? That systemd "created more race-conditions than it fixed", as you stated, or that systemd actually does solve race conditions, only that it is cumbersome to configure it?
        scbrg 6y ago
        Not OP. I suppose though, that the point is that a system in which things happen serially you don't really have race conditions. Things either work, or they don't. If they don't, it's because they happen in the wrong order. One of the (very many) things that gave me and my colleagues a headache when switching to Systemd was two init scripts that could run one after the other (and the order didn't matter) but they could not run simultaneously. This had worked fine with System V style init scripts that ran serially, but started breaking in Systemd. Of course you can now argue that this is a configuration error - however, it does not change the fact there there didn't use to be a race condition. Now there was one. One is a larger number than zero.
        hnarn 6y ago
        Just for the sake of discussion, if we assume any general, generic computer process that works fine serially breaks in a parallel environment, is that really a valid argument for or against parallelism? In the short term, things breaking like this are of course frustrating, but if it was my environment I’d prefer that this dependency was an explicit part of the configuration rather than something that works “by accident”, unless one prefers that initialization should never be anything but serial, but I personally at least don’t see the benefits of that outweighing what systemd offers.
        scbrg 6y ago
        > is that really a valid argument for or against parallelism? Not really. That wasn't the question though. The question was "were there more race condition with the parallel system than with the serial system?". The answer was undeniably, objectively yes.
- gorgoiler 6y ago
  A lot of init script writing was made easy for years with tools like the lsb* functions and start-stop-daemon. It would’ve been cool to have functions that supported dependency in the scripts themselves. A web server would have a call to... init_wait_for networking ...which blocks until some higher level networking script calls: init_ready networking ...but the standardised LSB header magic-comment stuff was also fine when it came to handling dependencies. Doing all this with INI files is very clever but it’s always felt very NIH. Good solutions solve existing problems without rewriting and embracing everything from the ground up.

ungamedplayer 6y ago

Casual admins made race conditions and other security bugs in init scripts.

welterde 6y ago
For me systemd created more race-conditions than it fixed (especially if the old init system started things serially). Getting it right in serial fashion is fairly easy, but since systemd insists on doing as much as possible in parallel you really need to have every dependency correctly configured (which is not always that easy to get right if things take a couple of seconds to get going..).
- kaba0 6y ago
  What? You have to specify a dependency in the .service file, what does it matter how much time does any of them take? That’s the whole purpose of dependency management. Either that is missing or you have some other config error, like the service believing it is ready, because it is not told about its state correctly? But there is a setting to fall back to serial mode I believe, but it will also not work correctly if your service files are configured incorrectly.
  - welterde 6y ago
    Exactly my point. You have to configure all dependencies correctly as well as have all the dependencies themselves configured correctly to make systemd aware at what point they are ready (which again can be non-trivial to do). It is much less forgiving to mistakes (and yes.. the little annoyance I am having right now has the dependencies set correctly, correct service type, systemd-analyze chain looks good.. so mistake is somewhat well hidden).
    - hnarn 6y ago
      What exactly is your point? That systemd "created more race-conditions than it fixed", as you stated, or that systemd actually does solve race conditions, only that it is cumbersome to configure it?
      - scbrg 6y ago
        Not OP. I suppose though, that the point is that a system in which things happen serially you don't really have race conditions. Things either work, or they don't. If they don't, it's because they happen in the wrong order. One of the (very many) things that gave me and my colleagues a headache when switching to Systemd was two init scripts that could run one after the other (and the order didn't matter) but they could not run simultaneously. This had worked fine with System V style init scripts that ran serially, but started breaking in Systemd. Of course you can now argue that this is a configuration error - however, it does not change the fact there there didn't use to be a race condition. Now there was one. One is a larger number than zero.
        hnarn 6y ago
        Just for the sake of discussion, if we assume any general, generic computer process that works fine serially breaks in a parallel environment, is that really a valid argument for or against parallelism? In the short term, things breaking like this are of course frustrating, but if it was my environment I’d prefer that this dependency was an explicit part of the configuration rather than something that works “by accident”, unless one prefers that initialization should never be anything but serial, but I personally at least don’t see the benefits of that outweighing what systemd offers.
        scbrg 6y ago
        > is that really a valid argument for or against parallelism? Not really. That wasn't the question though. The question was "were there more race condition with the parallel system than with the serial system?". The answer was undeniably, objectively yes.
gorgoiler 6y ago
A lot of init script writing was made easy for years with tools like the lsb* functions and start-stop-daemon. It would’ve been cool to have functions that supported dependency in the scripts themselves. A web server would have a call to... init_wait_for networking ...which blocks until some higher level networking script calls: init_ready networking ...but the standardised LSB header magic-comment stuff was also fine when it came to handling dependencies. Doing all this with INI files is very clever but it’s always felt very NIH. Good solutions solve existing problems without rewriting and embracing everything from the ground up.