What would you prefer happen instead? Having seen plenty of downtime caused by not having retries or hanging indefinitely weren’t exactly improvements in my experience.
"service didn't start, oh well"
"service didn't stop, force killing it"
Is just fine.
It's my responsibility to ensure the service is operating correctly, not all-for-one systemd. Redhat bloatware dictating how Linux should be.
I am aware that I can change the timeout of retries, but that's documentation overhead.
It’s prolonged downtime, that’s what it is, and it may make the system unusable. I saw that several times during the transition period where a network outage or data center shutdown meant that some important daemons failed on startup (one of them had the concept of retrying a connection error, but not a DNS resolution failure) and the admins of the SysV boxes had to manually restart everything while the Upstart & systemd boxes recovered almost immediately. One fun case had the developer almost getting this right: they had implemented retries but without a time delay or back off so their init script maxed out its retry count in a second of “host not found” errors and then exited permanently.
When you leave things like retries, logging, or dropping permissions up to each daemon you end up with a hodgepodge of incomplete implementations and things like error handling are where corners tend to get cut the most since the situations are infrequent and often hard to simulate.
IMHO, that's how I feel about systemd --- if a startup task is stalled, the system is non-interactive, unless something has changed since I last experienced this issue.
If some other operator access has started, you can use that, but the console is useless.
Really, it's only on you to fix it if it does not work, which in my experience is far less likely with systemd.
That's just lazy if your waiting for systemd to report you a failure. It's on you to maintain, ensure it's all operating correctly; including the daemon starting and stopping manually correctly.
Makes sense that on machines I've inherited that such checks are not done.
If they have access to the physical console, they can already permanently interrupt your boot process with an alt-sysreq, ctrl-alt-delete, and likely several other methods (power switch, or pulling the plug.) I'd say being able to gracefully cancel a timeout/retry would be the least of your worries.
