[tannhaeuser]

Best thing of systemd is that it's putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely.

I can tolerate systemd on desktops as long as I don't have to deal with it. The moment it craps out with Java-esque error traces in binary logs I'll install Slackware (or is there a modern desktop Linux without systemd I'm not aware of?).

Other than for desktops with complex run-time dependencies (WLAN, USB devices, login sessions), what are the benefits of systemd for servers that warrant a massive, polarizing, tasteless monolith which puts you up for endless patches and reboots, especially in a container world? (Re-)starting and stopping a daemon isn't rocket science; it's like 10 lines of shell code.

[dijit]

SystemD was so polarizing for me, I was a Fedora user and RHEL user for work- but it started consuming everything and giving really bizarre issues... I tried reaching out and explaining to people that it wasn't working in the way I expected or, asking them to point me towards the docs so I can at least learn how to use journalling properly so it doesn't hide issues from me.. and was met with some hostility.

When I asked to disable binary logging entirely because it kept getting corrupted and was opaque I was met with "Unlearn your old ways old man"-style responses and "You can just log to rsyslog too".. No, I want it disabled.. I don't have a desire to log twice..

It was then I realised I was at the mercy of systemd, they can push whatever and reject whatever and I'm completely out of control- I cannot introspect their service manager effectively, it's non-deterministic. It just reeks of hubris from the maintainers. It does mostly the right thing for most people, and they compare it to sysvinit which admittedly needed love. (and, was not a process manager, was only a process starter).

So, I adopted *BSD on the server. And christ is it wonderful.

I still use Arch/SystemD on my desktop at home, because it's actually pretty useful on laptops/desktops. But I swore a vow never to manage a server with SystemD on it.

I'm still runing RHEL6 at work, for the next OS, I'm pushing my very large corp to adopt FreeBSD as an alternative. That's a fairly large amount of money that Red Hat will lose and I don't particularly feel bad about it.

They forced my hand.

[tannhaeuser]

If you're deep into Fedora/RHEL, maybe you can make sense of the fakesystemd situation [1]. Supposedly fakesystemd helps to provide at least a systemd-free Docker container. I'd definitely hate to see CentOS/RHEL go away (which I've come to appreciate as a predictable, if conservative, Linux distro in the past).

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1118740

[JdeBP]

It's 10 lines of shell code to do it badly. Poor Man's Dæmon Supervisors written as shell scripts are inevitably flawed in one way or another. It is, however, easy to do with one of the many toolsets that have been around since the 1990s for doing this.

* http://jdebp.eu./FGA/daemontools-family.html

One of the exhibits in the systemd House of Horror results from people taking multiple Poor Man's Dæmon Supervisors written badly in shell script, nesting them inside one another, nesting the result inside another service manager, and then recommending against service management in toto because this madness goes badly wrong.

* http://jdebp.eu./FGA/systemd-house-of-horror/wso2.html

[tannhaeuser]

You certainly have a point re bad shell scripts. But imho advocating a wholesale service manager monolith like systemd isn't the answer (fallacy of the excluded middle and all).

Unix admins must come to learn what they're doing somehow. The way they learn it is by going one step after another, beginning with simplistic shell scripts controlling isolated functionalities, then improving it etc. Do one thing, and do it well, Unix philosophy, whatever. For novice Unix admins, systemd is too much of a black box, without any kind of didactic curriculum leading to it or away from it. Folks cannot grow into becoming a senior Unix admin.

I've seen it first hand just recently where a customer of mine went all-in (on puppet in this case). The "admins" were merely clicking around and doing trial and error kind of things; they had absolutely no idea what they're doing, and when things are going south won't be able to even diagnose what's going on. They hated their job and went out the door at 5pm. They stayed and were very eager to learn, however, when I gave them an ad-hoc Unix command line survival guide.

Systemd and its ilk is not how you get responsible and competent Unix admins that take pride in their work.

[digi_owl]

> Systemd and its ilk is not how you get responsible and competent Unix admins that take pride in their work.

I other words perfect fodder for Red Hat support contracts (anyone getting flashbacks of MSCEs?)...

[aaronmdjones]

> (or is there a modern desktop Linux without systemd I'm not aware of?)

I've been using Linux Mint, Debian Edition, as my main workstation OS for more than 3 years now.

It has systemd, but does not use it as init; it has a Makefile-style boot process as far as I know.

[vbernat]

> (Re-)starting and stopping a daemon isn't rocket science; it's like 10 lines of shell code.

That's why half of the SysV-style scripts to restart call sleep. No such unreliable hacks with systemd...

[marcosdumay]

Is any of those as easy to upgrade as Debian?

Because on servers, even the huge repository isn't that much of a gain. But running "apt-get upgrade" beats rebuilding a machine by orders of magnitude. Even more for rented VPS where I must either add an instance or get downtime.