4 ms·

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 fa

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.
        hnarn 6y ago
        I think the question posed is really odd, because race conditions cannot really exist as long as you only assume serial processing. I mean, the definition of a race condition means it's dependent on timing, which is an excluded risk if you're not attempting to start your services in parallel. So a better question in my opinion is: does the tradeoffs mean we should go back to serial execution? My feeling is no.
  - kaba0 6y ago
    Yeah I believe Rust is also much less forgiving to mistakes than C is, which makes it a bit less beginner friendly, but do we really want to allow badly written things to run? Also, are you sure it is a race condition? Some other errors can also appear as races. What service are you trying to create?
    - welterde 6y ago
      Not sure your analogy really works here, since languages like Haskell, Rust, etc. will tell you at compile-time that you have made some mistake. That's not how systemd (or any init system) works though. Things break at runtime. It sure would be nice to have a system that could tell me stuff won't work before running it, but that's just not possible. And my problem is the very definition of a race-conditions. It doesn't always occur and if I play with the timing a bit I can make it go away. The dependency unit is a oneshot script that adds some ip addresses to interfaces. The dependent job tries to bind to one of those ip addresses. And yes the interface is up before this all happens.

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.
        hnarn 6y ago
        I think the question posed is really odd, because race conditions cannot really exist as long as you only assume serial processing. I mean, the definition of a race condition means it's dependent on timing, which is an excluded risk if you're not attempting to start your services in parallel. So a better question in my opinion is: does the tradeoffs mean we should go back to serial execution? My feeling is no.
- kaba0 6y ago
  Yeah I believe Rust is also much less forgiving to mistakes than C is, which makes it a bit less beginner friendly, but do we really want to allow badly written things to run? Also, are you sure it is a race condition? Some other errors can also appear as races. What service are you trying to create?
  - welterde 6y ago
    Not sure your analogy really works here, since languages like Haskell, Rust, etc. will tell you at compile-time that you have made some mistake. That's not how systemd (or any init system) works though. Things break at runtime. It sure would be nice to have a system that could tell me stuff won't work before running it, but that's just not possible. And my problem is the very definition of a race-conditions. It doesn't always occur and if I play with the timing a bit I can make it go away. The dependency unit is a oneshot script that adds some ip addresses to interfaces. The dependent job tries to bind to one of those ip addresses. And yes the interface is up before this all happens.