[doublerabbit]

Leave the service dead, or just kill -9 the process.

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

[acdha]

> Is just fine.

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.

[toast0]

> It’s prolonged downtime, that’s what it is, and it may make the system unusable

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.

[bmicraft]

> It's my responsibility to ensure the service is operating correctly

Really, it's only on you to fix it if it does not work, which in my experience is far less likely with systemd.

[doublerabbit]

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

[bmicraft]

I've been running Arch continuously without a single complete reinstall for a decade now. I don't think it's fair to claim I wouldn't know how to maintain my systems correctly.

[doublerabbit]

I'm not advertently claiming you cannot. But working with teams and systems where they wear the badge of "I'm a DevOp who can SysAdmin" and try to prove themselves in such as a manner throws myself a sigh.

If your unable to compile your own kernel, you don't pass in my books, it's a rite of passage.

[bmicraft]

> If your unable to compile your own kernel, you don't pass in my books, it's a rite of passage.

Pulling the PKGBUILD (or similar for other distros) and throwing in a couple of patches before `makepkg`-ing it is the easy part. Of course you could do it manually, but then what's even the point besides bragging rights. Very few people have a reason build a completely custom system LFS style, and those that do will.

[doublerabbit]

I'm not talking about LFS.

The Linux kernel comes with thousands of different drivers for all kinds of devices which adds weight and such that even slows bootup times. For the home user, sure, default works best.

Why use a kernel with bluetooth modules, wifi modules applied when the actual server has none of that hardware? Not forgetting added security risks. It's all clutter and bloat that's not needed at all.

Do you really need to support a 1998 3Com IPX network card on your production server?

It's about understanding the system as a whole not just the userland or /etc/. Sysctls parameters and fine tuning the cogs that drive the system; the Linux IP stack is abystmal without tuning.

The default kernel works, but your not going to get near best performance without fine tuning and minimalizing the kernel. It's not a bragging excercise, it's a real excercise to ensure the system is secure and to ensure smooth operatation. You'll find these excerised in enterprises where such performance are a requirement.

Knowing how to compile your kernel is key piece of important knowledge to know and you'll find that someone with that knowledge will end up getting hired than someone without.

The saying is true: SysAdmins treat servers like pets; developers treat servers like cattle.