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.
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.