[throwaway_se099]

> Nothing in the documentation hinted that this was a feature of systemd anywhere

Nothing except three paragraphs in systemd.service(5) (TimeoutStartSec=, TimeoutStopSec=, TimeoutSec=), with references to systemd-system.conf(5) where the defaults are described. I wouldn't call that undocumented. Whether it should exist by default is another question; on balance, I'm glad it does.

[chaps]

This seems like the bug I was having at the time: https://github.com/systemd/systemd/issues/3912

Or this: https://unix.stackexchange.com/questions/227017/how-to-chang...

Or this: https://github.com/systemd/systemd/issues/5773

Or: https://github.com/systemd/systemd/issues/3901

Or: https://github.com/systemd/systemd/issues/2047

I don't remember seeing any documentation at the time, but I'm clearly not the only one who's had issues with this exact problem. The last one has recent examples of people not being able to find it, and understandably so. Their documentation is shit, fullstop, and no reasonable service should restart in a loop by default after 90s. That's just asinine.

[throwaway_se099]

This seems to be veering in the direction of the Land of Moved Goalposts and Non-Sequiturs, but I'm game for one more round, because lockdown.

It's rather unlikely that the first issue, which is an ordering problem during service shutdown, has much in common with timeouts during service startup, which you have described as your original issue.

The Stack Exchange question is a straightforward how-to for adjusting the timeouts.

5773 requests a clarification of the documentation of timeouts and signalling behavior.

3901 is a case of misplacing the timeout directive.

2047 is a sort of philosophical problem of reporting uniformity vs. consistency with manual configuration. The systemd team prefers the former, whereas I would prefer the latter for not violating the principle of least surprise, although I understand the reasons for choosing the first option.

Anyhow, I still don't see good support for your assertion of the complete lack of timeout documentation, just tangentially related distractions. A complex set of problems, and service management does qualify, will have edge cases, insufficiently clear documentation, and outright bugs, which is why software is never finished. Older init systems had all of these, but they didn't give you the tools to attempt to rectify the problems, so it was all more or less swept under the rug. Using a facile "shit, fullstop" characterization therefore tells me more about your views than the actual technical merits or documentation quality of systemd.

[chaps]

The post is about how systemd wasted lots of time, in a thread about software that has wasted lots of time. The issues around bad documentation and the specific issue (the last one is probably the issue I had, but this was five years ago lol. Knowing me and arch linux, I probably didn't have the full man pages installed, so the cli tools were the only thing I had available.) wasted me a lot of time and very clearly others, and that's exactly the point of this discussion!

Hell, to troubleshoot that issue, I even ran something like a `find / -exec strings -a '{}' ; | grep timeout` and found nothing that ended up being helpful. But I absolutely had some form of documentation, again likely the last link I provided which isn't simply a philosophical issue when it provides misleading information that would have ultimately fixed the issue if it gave more informative output!

You admit yourself that the documentation can be insufficiently clear with bugs, and it's true: systemd happens to have lots of time killing bugs. The whole point of this thread.

You're missing the forest for the trees, friend.