3 ms·

If systemd was written by someone with just a bit more taste in structure and APIs, I might believe you, but that just isn't the case. Why do I have to wait fo

by bcrl 6y ago

If systemd was written by someone with just a bit more taste in structure and APIs, I might believe you, but that just isn't the case. Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Why was ntsysv and chkconfig support (the baby) thrown out with the bathwater until almost a decade after systemd was introduced? The author has consistently demonstrated that he does not have the ability to make decisions that take into account the sysadmin / end user experience when things go awry. That's what frustrates me about systemd. At least I was able to debug the shell scripts that shipped with sysvinit. These days I have no control over that part of my machine. Fwiw, the same disease infected gnome a long time ago as well. One day my key bindings surprisingly changed from unix to windows style in an update. Then I lost the ability to customize the widgets surrounding windows by the window manager. Control over focus follows mouse was lost... It drove me away as a user because my preferences were no longer worth supporting. I guess I'm just turning into a grey beard at this point. Sigh.

SahAssar 6y ago
> Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Because one of your other services has said it depends on network.target/network-online.target and is in the critical path of your boot. Check which one with "systemd-analyze plot > plot.svg" and "systemd-analyze dot 'network.*' | dot -Tsvg >network.svg". You can also see the critical chain and which parts block faster boot with "systemd-analyze critical-chain". I think if you stopped expecting systemd to act like something else and instead treated it like the toolkit that it is you'd see that it does what it says it does quite well. Those issues with boot you mentioned are often that the distro ships a bad systemd config for a certain program.
- bcrl 6y ago
  Why do you think systemd is defendable for this? The prior init system had a means by which individual init scripts could be disabled during boot. I can't run systemd-analyze when the system off in lala-land for 5+ minutes. Moreover, if I know what is wrong, why can't I just cancel the job it's waiting for like I could previously from the console? It is a unacceptably bad user interface experience. There is no excuse for it. Again, this worked previously - why was this functionality lost / hidden? It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.
  - SahAssar 6y ago
    A service has been configured that to say that it won't start until the network is up. Another target, your user interface has said it depends on the previously named service. What is the correct action for systemd to take here? After a timeout it will do what you said it will do, but until then it will try to do what the configs have said it should do. You can tweak this however you want. You can shorten the timeout to whatever you want, you can change the dependency graph so that particular unit does not depend on the network, you can disable it completely. > It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs. I don't understand what you mean here, it was configured to do one thing, and it did that thing. You can of course say that it's a bad config (which is probably true), but then it's either the distro, the packager, systemd's defaults (which often are not ideal) or your own customizations. I'm all for arguing about better defaults in systemd and making distros better config their packages, but the actual systemd init seems to have done exactly what it was told to do here. Again, I'd like to say that distros/packages/users of systemd treat it like a pure init and often don't use it as intended. > I can't run systemd-analyze when the system off in lala-land for 5+ minutes. If the tree of critical services for your boot are that broken I'd assume you need to boot into single user mode or use a recovery usb. But if you actually boot after those 5min I'd expect you to easily find where those 5mins where lost using the tools I mentioned above, which is more than I can say for previous inits.
    - bcrl 6y ago
      Why does login on a console terminal depend on networking being up? It's a false dependency, one decided upon by the developer of systemd. And it was a poor choice. The mindset that "it's configurable" is inexcusably lame. That mantra allows bad developers to get away with not putting in the work of thinking about and understanding how users experience their software. It also allows rewrite-the-world projects to take off and throw out all the knowledge that is implicitly present in an existing system before having understood why that complexity came to exist in the first place. Those who do not try to understand history are doomed to repeat it. That has clearly happened in the case of systemd and is why I don't think the attitude it presents towards end users is at the level that such a core piece of infrastructure should display.

by bcrl 6y ago

SahAssar 6y ago

> Why do I have to wait for several minutes to boot or reboot my machine when something goes odd with one of the services (like dns not working due to a transient network issue)? Because one of your other services has said it depends on network.target/network-online.target and is in the critical path of your boot. Check which one with "systemd-analyze plot > plot.svg" and "systemd-analyze dot 'network.*' | dot -Tsvg >network.svg". You can also see the critical chain and which parts block faster boot with "systemd-analyze critical-chain". I think if you stopped expecting systemd to act like something else and instead treated it like the toolkit that it is you'd see that it does what it says it does quite well. Those issues with boot you mentioned are often that the distro ships a bad systemd config for a certain program.

bcrl 6y ago
Why do you think systemd is defendable for this? The prior init system had a means by which individual init scripts could be disabled during boot. I can't run systemd-analyze when the system off in lala-land for 5+ minutes. Moreover, if I know what is wrong, why can't I just cancel the job it's waiting for like I could previously from the console? It is a unacceptably bad user interface experience. There is no excuse for it. Again, this worked previously - why was this functionality lost / hidden? It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.
- SahAssar 6y ago
  A service has been configured that to say that it won't start until the network is up. Another target, your user interface has said it depends on the previously named service. What is the correct action for systemd to take here? After a timeout it will do what you said it will do, but until then it will try to do what the configs have said it should do. You can tweak this however you want. You can shorten the timeout to whatever you want, you can change the dependency graph so that particular unit does not depend on the network, you can disable it completely. > It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs. I don't understand what you mean here, it was configured to do one thing, and it did that thing. You can of course say that it's a bad config (which is probably true), but then it's either the distro, the packager, systemd's defaults (which often are not ideal) or your own customizations. I'm all for arguing about better defaults in systemd and making distros better config their packages, but the actual systemd init seems to have done exactly what it was told to do here. Again, I'd like to say that distros/packages/users of systemd treat it like a pure init and often don't use it as intended. > I can't run systemd-analyze when the system off in lala-land for 5+ minutes. If the tree of critical services for your boot are that broken I'd assume you need to boot into single user mode or use a recovery usb. But if you actually boot after those 5min I'd expect you to easily find where those 5mins where lost using the tools I mentioned above, which is more than I can say for previous inits.
  - bcrl 6y ago
    Why does login on a console terminal depend on networking being up? It's a false dependency, one decided upon by the developer of systemd. And it was a poor choice. The mindset that "it's configurable" is inexcusably lame. That mantra allows bad developers to get away with not putting in the work of thinking about and understanding how users experience their software. It also allows rewrite-the-world projects to take off and throw out all the knowledge that is implicitly present in an existing system before having understood why that complexity came to exist in the first place. Those who do not try to understand history are doomed to repeat it. That has clearly happened in the case of systemd and is why I don't think the attitude it presents towards end users is at the level that such a core piece of infrastructure should display.