5 ms·

I agree; not so much that I've found systemd to be unreliable, so much as that it is far more opaque than even the most involved SXX/KXX SysV shell script; I ca

I agree; not so much that I've found systemd to be unreliable, so much as that it is far more opaque than even the most involved SXX/KXX SysV shell script; I can debug a shell script, but when systemd does do something unexpected, it's utterly inscrutiable.

hackerbrother 3y ago
I will take the opposite opinion. I think that systemd overall reduces the quantity, or surface area, for bugs by making many standard types of service requirements for dependencies, restarting, etc. simple configuration options.
- bandrami 3y ago
  Right but you never see what it's actually doing like you do with sysv. You have a high-level description of what you want to happen and when it messes up (invariably at 3am, invariably on a mission-critical system) you're completely in the dark about what it's trying to do. You can (and people do) mitigate this by just writing imperative startup scripts that systemd calls, but then that leaves the question of what the point is.
  - kaba0 3y ago
    Managing services and dependencies and orchestrating all of that is the point. That orchestration “boilerplate” has to be correct and you can reasonably know that it is with a program made for that. If you mess up your service’s config, the problem will be local (your service won’t start), while without a declarative stance your whole system would be in an inconsistent state.
    - bandrami 3y ago
      Wait, no; you're describing the exact opposite of what happens. If a sysv init script gets messed up that service fails and the system trundles on. When a unit file is wrong the whole server just sits there refusing to do anything while it waits for 30 seconds, them 90, then 120... OpenRC is closer to systemd than sysv in that regard, though at least it logs sanely
      - kaba0 3y ago
        > while it waits for 30 seconds, them 90, then 120... That depends on how it’s configured, but that is the correct behavior under the given config. You can specify timeouts, or what depends on what and most of it is sane. For example, what would be the logical thing to do with a server that has no internet connection? You can only wait for that.
kaba0 3y ago
You can debug a shellscript, but can you debug the complex orchestration of many of them with a stateful and error-prone hardware system beneath it is responsible for upbringing? It can’t even log during the early boot phase, while systemd has that solved as well.
- linksnapzz 3y ago
  Yes. I've done that plenty of times on Solaris (pre 10); including logging at the PROM level...

hackerbrother 3y ago

I will take the opposite opinion. I think that systemd overall reduces the quantity, or surface area, for bugs by making many standard types of service requirements for dependencies, restarting, etc. simple configuration options.

bandrami 3y ago
Right but you never see what it's actually doing like you do with sysv. You have a high-level description of what you want to happen and when it messes up (invariably at 3am, invariably on a mission-critical system) you're completely in the dark about what it's trying to do. You can (and people do) mitigate this by just writing imperative startup scripts that systemd calls, but then that leaves the question of what the point is.
- kaba0 3y ago
  Managing services and dependencies and orchestrating all of that is the point. That orchestration “boilerplate” has to be correct and you can reasonably know that it is with a program made for that. If you mess up your service’s config, the problem will be local (your service won’t start), while without a declarative stance your whole system would be in an inconsistent state.
  - bandrami 3y ago
    Wait, no; you're describing the exact opposite of what happens. If a sysv init script gets messed up that service fails and the system trundles on. When a unit file is wrong the whole server just sits there refusing to do anything while it waits for 30 seconds, them 90, then 120... OpenRC is closer to systemd than sysv in that regard, though at least it logs sanely
    - kaba0 3y ago
      > while it waits for 30 seconds, them 90, then 120... That depends on how it’s configured, but that is the correct behavior under the given config. You can specify timeouts, or what depends on what and most of it is sane. For example, what would be the logical thing to do with a server that has no internet connection? You can only wait for that.

kaba0 3y ago

You can debug a shellscript, but can you debug the complex orchestration of many of them with a stateful and error-prone hardware system beneath it is responsible for upbringing? It can’t even log during the early boot phase, while systemd has that solved as well.

linksnapzz 3y ago
Yes. I've done that plenty of times on Solaris (pre 10); including logging at the PROM level...