i hate systemd

The Good, The Bad, The Ugly.

And The Survival Guide.

(Work In Progress)

The Bad

Here are some of the bad things about systemd.

22nd June 2018: Renaming Network Interfaces.

As announced in the systemd mailing list, version 239 of systemd will name network interfaces differently than in previous versions.

Because breaking the name of my network adapter is exactly what I was asking for.

There are a whole set of other changes in the same announcement which should make it clear to any sane person contemplating switching over to this system that it is not yet ready for production use. The definitions of blacklist/whitelist have swapped over; a hibernate update notes that "swap files should work for hibernation now." - because it's absolutely fine to "support" hibernation for years, for 239 releases, without hibernation actually, well, working.

Pwnies 2017: "Lamest Vendor".

The annual pwnie awards awarded systemd its "Lamest Vendor" prize in 2017, due to its handling of bugs 5998, 6225, 6214, 5144, and 6237. The Register has more details.

Dynamic Users

Dynamic Users is a feature added between v232 and v235 of systemd. There's a blog post by Poettering here.

What is a Dynamic User, you ask?

Well, it's a system account which is created when the service starts, and is deleted, along with all the files owned by that user, when it stops. And yeah, that's about as stupid and dangerous as you might imagine it to be. It claims that it avoids the "problem" (have you ever encountered this problem?) with the numerical limit on available UIDs and GIDs, yet it also allows for persistent directories - you know, just in case you wanted your data to still be there after you've restarted the service! (some people are *so* fussy about actually *keeping* their data, I don't know!).

But it keeps them hidden under "chmod 0700" root-owned directories. Then they realised that if you start the service up again, and another process has taken your previous UID, then they'll have to do a recursive "chown -R" on your data, so you'll just have to wait for that to complete before you can start the task of actually starting up your application. Heaven forbid it'd be a large amount of data, or on a slow, or read-only, or remote media such as NFS.

Given systemd's history in terms of security and protection of user data (that is, the designers simply don't care about such things), it will only be a matter of time (the blog post above was 6/10/17; this rant was written on 17/10/17; I'll try to remember to update this piece when I hear of the first example of inadvertent data loss or exposure caused by systemd as soon as I hear of it) until this implementation loses somebody their data. That is, if anybody is stupid enough to make use of this "feature" in the first place. Which does seem unlikely, since it's solving a problem that nobody has ever reported. Ever.


CVE 2017-15908 has the full details, and you can read a bit more in plain-English from Ubuntu, but in a nutshell: a given DNS response (so far, I believe, the details have not been made public) will cause systemd to hang entirely. So a total Denial of Service (DoS) attack on your ability to manage your system.

Wow - nobody ever warned that there was a massive danger inherent in putting so much arbitrary code into PID 1, did they?

Oh, wait. They did. Yes. Absolutely everybody did warn them about this huge, monolithic, unwieldly PID 1 process taking control of so may existing subsystems, with the potential for new bugs in any one of them to affect the stability of the entire system. Many times. We did that. But systemd rolled on anyway. And broke a lot of systems for a lot of people.


There's always more ...