This is non-init related systemd from IBM->Red Hat->Fedora in a nutshell. It's good for fleets of mega-corp servers. It's bad for human people running linux desktops. But since IBM is the primary entity paying people to write non-init systemd is everywhere and only niche distros avoid it.

Have you ever met someone running fleets of mega-corp servers who was a fan of systemd?

When I've seen them complain the systemd people tell them that they're just stuck in their ways and that systemd is a revelation on desktops where users don't have the historical unix experience holding them back...

I and multiple of my coworkers love systemd. We work in a "hyperscale" environment and we moved from sysvinit through Upstart to systemd at scale, predominantly on RHEL and a little Debian. We were all skeptical at first. But sysvinit and Upstart both sucked for various reasons, and we had tried to work around the warts. systemd has mostly solved all of those problems for us. Some of the things that systemd improved:

Init scripts suck to test and debug. When manually-called, the caller's environment would get used, rather than a clean env, which would cause problems with the poorer-quality scripts. These showed up multiple times in production where an engineer would bounce a process manually and it got some configuration from their environment. We took some steps to alleviate this, like encouraging use of `service`, but using the scripts directly was reflexive for most because of years of indoctrination and it's portability to some other operating systems. systemd eliminated this entire class of issues, because unit files are just config files, not scripts.

Dependencies actually work. Usually, this came up when needing to wait on the network. With systemd, this is just a single dependency in the unit file. It also meant we stopped having to manage S## and K## which became something of a time-consuming art on machines with lots of services.

Not exactly init system, but systemd's triggered units absolutely destroy cron. Manually running a job (e.g. when testing or when a run failed) guarantees the same environment, whereas cron has no similar capabilities. It also actually keeping status means we can more easily see if the last run succeeded. This may ease our monitoring burden, too, but we haven't gotten to give it attention yet.

Certainly no one loves whatever hellhole preceded systemd. It turns out that (some) complexity is non-reducible; if a declarative, properly solved service manager doesn’t cut it, then neither does that shitty ad-hoc bash script system abomination with race conditions.

If systemd were just a declarative sysvinit alternative I don't think there'd be near the pushback.

Manage a fleet of at least 15k systems here, I enjoy systemd at times

Other times, like oomd, I just want it to get out of the way.

Service dependencies are an area I love. With systemd making a service robust around dependencies like mounts and other services is a cake walk.

If you have manual hand-holding processes on services running under systemd, I suggest looking into supplying these kinds of directives.

    - Requires / Wants
    - Before / After
    - PartOf

I'm torn for networkd. The configuration of interfaces is nice and simple, I've grown to like the link, netdev, network concepts/files.

However, forwarding is significantly different. I'd think twice about using it on a system doing NAT/masq

I've just heard from people claiming the absurd way NIC are named in systemd is good for server fleet types and the like. Because it's obviously terrible for human people with desktop computers. I guess I just assumed the bad design decisions had some purpose.

I miss the old NIC names, but for systems with multiple NICs the old way would name them differently based on the winner of the init race. It often felt deterministic, but was not.

I've had critical systems fail on reboot because the NICs swapped names so WAN port got configured as LAN and vice versa. That can also create a terrifying security problem too

Some distros wrote config files so the assignment would remain stable.

Which also was wrong when switching hardware around, but that's a different issue.

It provides predictability in the device names. enp1s0f0 looks cryptic but it tells you the exact slot location of the card

eth0 tells you the first ethernet class interface that was activated that boot. Not particularly helpful.

I feel like if you need to care about these names as a user... the distribution has failed to provide effective wrappers. This is window dressing.

Yes. When we got a shipment of 1000+ servers that are all supposed to be cabled the same way, both internally and externally, the device naming made it easy to see when something got messed up. This allowed us to hold the system builder accountable, simplify our configuration management, and reduce the amount of configuration discovery a engineer needed to do during an incident.

Very good examples of the practicality!

While sure, I would like shorter device names, the fact is... the only time I need to use them is when ambiguity is something I/we can't really afford.

So, I'm thankful for the cryptic-yet-specific names.

Everyone else (read: desktop people) can use whatever DHCP'd.

o/ I'm not a systemd fan but I'm not a hater either. I think it does its job and, although it was a bit immature when initially released (especially by Fedora) it has matured into a very good init system that does it job. But yes, Fedora keeps pushing for the bleeding edge, but its users should know this by now.

Yeah. That's also mostly my opinion too. Systemd itself is okay. Just another init system, does some things better, a few things are kind of stirred around for no gain. What I've less been a fan of is the rider tech, networkd, their ntp support, oomd, all of which have more issues and don't seem to be converging. But if they do become stable I expect some new broken tentacle arm to form. :)

okayness meter decreased another notch today: system was ignoring fstab changes. turns out that systemd now handles fstab and you have to trigger the service to re-read the file if you edit it.

At least it doesn't require a reboot. Yet.

It’s particularly good on servers. All preceding systems were much worse.

It’s only useful on desktop because of its similarities with launchd, which is particularly good on desktop.

They don't love systemd because they only interact with it when they're debugging Asok the intern's broken services.