61–70 of 83 posts
Earlier quoted context omitted.
It might actually, if a network connection is temporarily down.
Or a disk not attached yet. Or another service it depends on being slow to finish starting up.
This is one of those things.
The 'After=' and 'Requires=' directives address this.
Depends on a mount? Point those directives at a '.mount' unit.
Depends on networking, perhaps a specific NIC? Point those directives at 'systemd-networkd-wait-online@$REQUIRED_NIC.service'
Point being: declare these things, don't wait for entropy to eventually become stable.
Earlier quoted context omitted.
Regardless, all this opinionated settings should be by OS maintainers or similar. I don’t see why a low level init system tries to make decisions for others. Yes, it may be with good intentions, but don’t.
The amount of times i had to fight and debug systemd compared to any other init system is at least 10x. Yes it does a lot of stuff for you and in others I had to write custom scripts but it was much more understandable and maintainable long term. Sadly systemd won and now i build my own OS without it.
Earlier quoted context omitted.
Or a disk not attached yet. Or another service it depends on being slow to finish starting up.
So, you two know how systemd gets heat for doing too much, right? This is one of those things. The 'After=' and 'Requires=' directives address this. Depends on a mount? Point those directives at a '.mount' unit. Depends on networking, perhaps a specific NIC? Point those directives at 'systemd-networkd-wait-online@$REQUIRED_NIC.service' Point being: declare these things, don't wait for entropy to eventually become sta…
Earlier quoted context omitted.
It's literally described in the article.
They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole. Hence.. why I called it a fragile mechanism.
> Why does systemd give up by default? > I’m not sure. If I had to speculate, I would guess the developers wanted to prevent laptops running out of battery too quickly because one CPU core is permanently busy just restarting some service that’s crashing in a tight loop. sigh … bounded randomized exponential backoff retry. (exponential: double the maximum time you might wait each iteration. Randomized: the time you wa…
Arguably, this logic should live in another place that monitors the service. Especially that service startup failure is usually not something that gets fixed on its own, like a network connection (where exponential backoff is (in)famous). A bad config file, or a failed disk won’t recover in 10 minutes on its own, so systemd’s default makes sense here, I believe.
At my work, we have a simple philosophy for this. The tester is allowed to (on the test system): toggle servers' power; move around network cables; input bad configuration; etc; in any permutation he wants. So long as at the end of the exersise everything is setup correctly the system should function nominally (potentially after a reasonable delay).
There should, of course, be a system level dashboard that notifies someone there is a problem; but that is unrelated to the server internal retry logic.
> Why does systemd give up by default? > I’m not sure. If I had to speculate, I would guess the developers wanted to prevent laptops running out of battery too quickly because one CPU core is permanently busy just restarting some service that’s crashing in a tight loop. sigh … bounded randomized exponential backoff retry. (exponential: double the maximum time you might wait each iteration. Randomized: the time you wa…
Regardless, all this opinionated settings should be by OS maintainers or similar. I don’t see why a low level init system tries to make decisions for others. Yes, it may be with good intentions, but don’t.
Earlier quoted context omitted.
They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole. Hence.. why I called it a fragile mechanism.
It's funny how some people call systemd overcomplicated and here we have someone complaining because it only has two levels (default/specific) for config instead of three (default/specific/forced default).
Earlier quoted context omitted.
They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole. Hence.. why I called it a fragile mechanism.
It's trivial to grep all system service files for the relevant lines to see if they override the default. It is also easy to override that override to set it to whatever you like of so desired.
Yes, there are ways to deal with anything, but less is more, this is unix afterall. I can't love having a bunch of options, in several places, that may override each other, most of which I would never use for any practical reason anyways.
Reminds me of the type of systems I abandoned in favor of linux.