Readit NewsI'm almost certain someone got paid off and pulled some stings. They don't do anything unless money is involved.
I disagree. They could have done it to be under the spotlight and progress their career.
/etc/systemd/{user,system}.conf.d/dont-wait.conf:
[Manager]
DefaultTimeoutStopSec=5s
You can stop hating on systemd now, everything you needed was in `man systemd-system.conf` all along.
[1] https://community.kde.org/Distributions/Packaging_Recommenda...
Here's another example of cultism repressing any dissent.
Let me make a bullet points list for you:
* I do not hate systemd, I have never stated that, I have been using it for possibly longer time than you and love most of it
* I am entitled to write about what I don't like, you can disagree and move on, we all need to do this exercise on a daily basis
* there are cases where systemd will change the order of dependencies during boot, that's by design because systemd works in a way that tries to achieve states. It's not really enforcing a graph with order
* in a sufficiently complex system, this constitutes a source of non-determinism and it is basically undebuggable: you see the failure, learn about the corresponding configuration, change it and hope that you did the correct change (you have no way to test this until next random occurrence)
That's all, it's based on my experience; I write plenty units on a regular basis and 99% of the times everything goes very well.
Plenty of people changes systemd configuration all the time and it just goes fine. You live in fantasy.
Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer blaming systemd.”
It takes no time whatsoever to get a boot graph with each services name and starting time. That’s an actual feature documented in the manual of systemd which solves OP issue. But of course it would require actually understanding something new and everything new is bad, isn’t it?
"since I have never experienced what you say, it must be fantasy"
> Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer blaming systemd.”
This is a perfect example of toxicity; I have been successfully using systemd for years and I am entitled to point out what I dislike, I do not have to love everything of it, it's not a religion nor a cult. Your reply tells more about yourself than the topic of the discussion at hand.
> It takes no time whatsoever to get a boot graph with each services name and starting time. That’s an actual feature documented in the manual of systemd which solves OP issue. But of course it would require actually understanding something new and everything new is bad, isn’t it?
You're missing the point, the problem is not changing timeouts but preventing failure and achieving an overall deterministic behaviour out of your system, without ignoring failures. But I refuse further eating these baits, you seem more interested in creating some flames rather than having constructive discussions.
I think this right here hits at the crux of the issue.
There are people who like systemd because it's integration-tested with itself and its own defaults, so if you never change those defaults you don't have many problems.
Then there are people who don't like systemd because if you do have to change any of its defaults, it often doesn't go well. And, of course, the latter behavior as a box users are expected to live in is poisonous, because everyone is being conditioned to be passive and uniform.
That’s an issue with a daemon, not systemd. Anyone who used NFS saw that routinely on SysV init during the era when Red Hat distributions shut down networking before ensuring that the network mounts were unmounted.
What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?
In a couple cases the only remaining issue was the lack of a RND() function definition