[sevagh]

Systemd is Godsent for people who have to administer diverse Linux boxes.

I can see how people who want to run their own tight ship on their machine would balk at it. I also sort of hate the systemd-resolv and the fact that it instantly rendered worthless 99% of online guides of how to unfuck your local DNS resolution.

[forinti]

I had no opinion on systemd until I found out I could configure the mount points in fstab to magically mount themselves whenever they were needed.

I have a lot of network shares and some of them caused real trouble when they failed for whatever reason.

Now I really appreciate it.

[pi-e-sigma]

Various automount tools have been available since the 90s.

[mariusor]

Indeed, why use Dropbox, when FTP existed for decades?

[pi-e-sigma]

Except these automount tools provided exactly the same functionality that is currently provided by systemd. And did it better

[bravetraveler]

I contest 'better'. What's the difference? It's mounted... no?

Allowing 'systemd' to be aware of mounts lets you create dependencies between your mounts and services.

For example: 'Requires=mnt-myfs.mount' (and 'After').

Use 'PartOf' if you want the service to get restarted during an unmount/re-mount.

This integration is mint! Anything not systemd [when it's already managing your services] trying to orchestrate is, by nature, second-rate

One may note the removal of the fstab generator. It's overblown. Any distribution including systemd vendors it.

[pi-e-sigma]

You obviously haven't used any of them and I have a feeling that in fact you haven't used anything but systemd because your remarks about systemd ability to create dependencies between mounts and services as something amazing is just hilarious.

[znpy]

Agree, but tou had to

[doublerabbit]

> Systemd is Godsent for people who have to administer diverse Linux boxes.

I disagree whole hearty. With 15 years of system administratorship, me and systemd don't get on.

Services timing out on start-up/shutdown, "waiting x/y -- x/y retries and hijacking resolv.conf are my common two.

[acdha]

> Services timing out on start-up, "waiting x/y -- x/y retries

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.

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

[icedchai]

At least let me cancel it from the console easily: control-c and continue. Waiting on retries that are never going to succeed is incredibly annoying.

[op00to]

Shouldn’t you need a password to log in? Seems bad to just let a some rando interrupt your boot process. It’s pretty easy to modify the timeouts that bother you.

[icedchai]

The timeout issue is often a temporary issue after an upgrade. I need to get into the machine to debug and fix it, but I'm delayed waiting for the timeout.

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.

[viraptor]

If "some rando" has access to the console keyboard while the system is being booted and some service is timing out... You've got a bigger problems than the fact they can cancel the start-up of that service.

[icedchai]

I often run into these sorts of issues when upgrading Ubuntu. A couple times, with major upgrades, it decided to rename network interfaces, resulting in various systemd services taking minutes to time out and continue. It would be nice if I could at least control-c it from the console. Super annoying when you're debugging things and have to wait minutes between cycles.