Welp, its official, with Debian Buster adoption into our mainline, we are officially switching from Sys-V-Init to SystemD.

I still do not know how I feel about it.

From the professional point of view - Its a relief. SystemD has so many more neat features that make the life of a sysadmin easier. If any, I love that it tracks the uptime of a service, making it incredibly easy the last time it crashed / restarted...

On the other... I just... Am kind of afraid where the whole systemd environment will go with time... And... I guess... I am also worried about how much systemd is taking over in the system itself... It will mean learning quite a few new services, debugging routines and such...

A new era of GNU/SystemD/Linux is upon us.

Is this from a movie? It sounds like a movie.

Microsoft: hey Linux is pretty shitty actually, so we can make Windows 10 crappy and still be ahead.

Linux community: hey Windows 10 is pretty shitty so that we can get away with more crap than before.

@Fast-Nop
That's the actual strategy of Poettering and Sievers.

Everything is shitty if you don't know enough of it.

Here the one uses shitty, bloated scripts where you don't know what happens when and in which sequence, with different workarounds for different distros. The other one uses a shit ton of services and scripts hidden in gazillions of subdirectories where you don't know how to set up anything non-standard.

At the end you'll always end up googling shit, copy paste it hoping it works, and fucking it up by yourself because the googled stuff doesn't fit you needs.

But to be honest, you can learn anything, it's just software.

@PublicByte I don't get the context, but yes, you're right, everything is shitty, it's just the level that changes.

@ddephor And some things get only more shitty the more you learn about them.

The only thing about systemd that relieves me is that someday, Lennart Poettering will die and stop making things worse.

Honestly I wasn't all too fond of init scripts, they were a horror to maintain and debug. So...yeah. unless somebody comes up with a better system, I'll go with systemd.

@RememberMe Systemd helped me to shift the blame to the guys that developed it. It was a Tomcat APP that communicated with 6 other programs. At first it was a pain to Debug it, since it was thrown into the background and Any output was discarded. After that i created 6 systemd-services and i was able to See that passwords were wrong, files were missplaced and other things. It helped with the monitoring too, so we could stop an rouge service after an update.

@halfflat like OpenRC you mean?

The thing about SystemD is simply.

If it would follow "do one thing and do it well" I'd be happy with it.

But... You know these dinner parties where everyone does exactly one frigging dish he or she's good at... And then comes BLEEP who bring's two dozens of fuckup to the table cause "You know I couldn't decide what to make but you'll gonna love it cause it's BLEEP BLEEP BLEEP BLEEP". And you just think.... Damn... This is not death row. We'll have to throw all that shit away just because you thought you we're a special snowflake and failed hard.

That's systemd.

Only systemd? Okay.

But... Networking? Home directory control? Container's? Locale settings? User Init? NTP / RTC settings? Logging? Audiring? Sending to remote location? Booting? Boot verification? Mother of DNS resolve? Security isolation? Limit CTL? Environment override? Mount handling?....

It's just too much. And every piece of it can fail hard... Leading to a completely borked system.

Not to mention that sometimes new defaults are added... Which can completely break you.

PrivateTmp eg. I thought I was going nuts till I realized that.

@IntrusionCM so what you're saying is... the thing that handles kernel requests and loads things as needed... shouldn't do that? Additionally, systemd has been the most stable part of completely fucked distros and installs for me, so it works pretty well if I can rarely break it when *trying*.

@Parzi I'm not sure what you mean (the thing that handles kernel .... as needed).

I was saying two things:

1) SystemD isn't modular, so "every piece of it can fail hard... Leading to a completely borked system". And yes.... I would like the modular approach...

2) sometimes new defaults are added.
That is the part where it get's nasty. I've "supported" (as in maintenanced) SystemD units from the beginning.

As SystemD continuously adds new parts and settings, upgrades can really be painful.

As an example I mentioned PrivateTmp. Which isolates a System Temp Folder so it is only visible to the service process.

While it might be a nice idea... it's terrifying when you know that a service wrote to tmp and there is nothing there.

And that's a thing I really dislike about SystemD - it broke a lot of workflows and tried to make them better (Init Bash Scripts / OpenRC)
So far so good.
But as it adds more features and changed sometimes even the service definition meanings...

And that's for me a No-Go.
While it might not be visible as a end user on a fixes desktop, it's pretty visible from an admin perspective.

Needing to rewrite self made Service Units every OS release and having to add them to the packaging, provision ing and so on is... Narf.

@IntrusionCM I cannot agree enough.

My biggest issue with SystemD is how it tries to be a jack of all trades and take over, an I am exaggerating here, every bleeping system service traditionally managed by an independent pluggable daemon.

The beauty of Unix and Linux was its modularity - Disliked how one service did things? Could replace it with a fork that did it different.

Sure, we don't *have* to use systemd's plentora of services and APIs but... All the other services we run that use push us to... And there's no way in hell we would modify or hack standard services to use a different API.

One example that made my blood boil is when PHP-FPM, our CGI of choice, introduced a dependency on one single stupid SystemD library, and suddenly, we were forced to install the whole of systemd on all of our up to date systems. Sure, it didn't force us to actually switch the active init daemon, but... Why...

One library. One stupid library and suddenly we had to deal with internal tools going haywire because they found, albeit nonfunctioning, systemctl on sysvinit systems!

Even major packages can run into issues then!

Most notably, Elasticsearch, had a bug where it checked for the init daemon in use just by if it found systemctl, and if it did, it tried to use it during uninstallation.

Guess what happens when systemctl failed to talk to the main systemd bus? Yep, prerm script fail, uninstall fail, dpkg error... That's just so stupid, the modularity is disappearing, and its making me mad.