Thursday, October 2, 2014


What's really wrong with systemd?



Unless you've been living under a rock or on a park bench during the past two years, you've probably heard of systemd and the numerous issues and controversies involved. You probably also have also heard about some new alternatives.

Now instead of boring you with long lengthy arguments and debatable concepts and anecdotes, I'm going to boil the core problem with systemd down to two simple points:

  • The singular aim of systemd is to get other projects to depend on it.
  • The systemd developers have a track record for not knowing what they're doing, thereby creating very fragile and unwieldy problematic software.
Now if you're looking for proof of these two points, you're free to read through the aforementioned pages I linked to, as well as search online for more. I hope you've enjoyed my summary.

6 comments:

henke37 said...

Aw, but I like "long lengthy arguments and debatable concepts and anecdotes". I guess the links will have to supply those instead.

ava1ar said...

Do you have any issues with systemd? Have you tried it? Or you just posting links to the other people's boring posts about the topic they do not completely understand? Systemd just works and works good - I am using it on 3 different kind of systems, including embedded and have no issues with it at all.

Joe P. said...

ava1ar, your comment highlights perfectly the sheer idiocy of the masses. "It works correctly in my narrow set of ordinary cases, therefore it must be that it works correctly in all cases." Alternately, "It works correctly right now, so it'll probably still work correctly in future releases." Sorry, no, that's not how the world actually works. Unless something has been guaranteed to account for exceptional cases and designed in a way that the amount of complexity won't grow as it's developed, you cannot call it stable.

Engineering 101: The easiest way to ensure that something properly handles all cases now and in the future is to compartmentalize tasks into the smallest unit possible, so that the number of possible cases is limited, can be easily tested, and will limit the damage caused by any error to one small area. Do one thing and do it well.

systemd on the other hand, takes the approach of "do one thing in a mediocre fashion, and then while we're at it, let's do a bunch of other things equally poorly". This concept of "boot system and service manager" is nice in theory, but the way and place where it's implemented (e. g. PID 1, running as root) means that it needs to be assuredly bulletproof. If there's even a single error in this process that causes it to crash, the entire OS will go into kernel panic (this is aside from taking down ALL services). If there's even a single exploitable vulnerability, your system is now subject to a root-level attack. The amount of complexity in systemd's design practically assures that there will be an error somewhere. Even if by some grace of God Himself the current code is 100% flawless, the complexity is almost guaranteed to grow as more things are added. This makes it nearly impossible to fully test.

We've been shown time and time again that the more complex a system is, the more likely it is for things to fall between the cracks. We've been shown time and time again that mission-critical systems with too much complexity lead to terrible vulnerabilities. Look at the past year, look at Heartbleed, look at Shellshock, these things happened because systems were misdesigned in a way that made errors difficult to spot. systemd is no different. How long is it before they announce what will be known as the "systemdeath" bug?

Also, "works well", not "works good". Learn English.

insane coder said...

Hi Joe P.

The real question is "works well" at what exactly?

As I indicated in my first "problem point", its only goal is to get other software to depend on it. The way to gauge that working well is either by sheer amount of projects that depend on it, or percentage of projects that depend on it. Something which the sane among us will hope remains as low as possible, in other words, the less it achieves of its primary goal, the better.

Now if we look at what the sheep are saying it's supposed to accomplish, there's two objectives you hear discussed most:

1) System management:
It's supposed to manage the applications running on your system.

Now there's something we already have that does that, it's called an Operating System - Linux in this case. If the OS is lacking, expand it. If it's not the place of the OS, then the individual applications or system libraries they depend on should be dealing with the issues.

Even if there is a place for "system management" like this, based on the track record of those involved, they're the last people we'd want to be working on such a project.

2) Boot system:
It's supposed to handle system boot up, and a few related issues.

If this is the goal, then for this kind of project, it should be fairly straight forward and rather stable. You should rarely be seeing any kind of updates. Having dozens of people working on it constantly is very disconcerting.

Your concerns along the lines of Heartbleed and Shellshock are very well placed if this is supposed to be the intended goal of systemd.


Returning to my first point, and how this project is viewed by other projects is crucial. If this is supposed to be a new intelligent way for all system daemons to be designed, which is supposedly sane, then it should be standardized by POSIX or similar, and developed in a portable fashion, as it has a broad portable goal.

If this is supposed to be a special new major component of Linux based Operating Systems, then it should be viewed as such. Anything depending upon it should label itself as Linux-only.

You can't have it both ways, either it's Linux only, as is everything depending upon it. Or it has broad applicable everywhere goals, in which case the design should be standardized so it can be implemented everywhere, or the application suite itself should be as portable as possible so it can be used everywhere.

Right now, everything is up in the air. Aside from various propaganda, nothing is clear. Personally, unless the status quo changes, I'd define this as a new kind of virus, and one which is designed to trick inexperienced developers and system maintainers.

smihaila said...

Hi,

Your asprintf() custom implementation may have a small bug: missing a basic validation on the strp arg. If the caller happens to pass NULL for that double char pointer, the line with

else { *strp = 0; }

will cause a 'null pointer dereferencing' situation.

insane coder said...

Hi smihaila,

This is the wrong article to be making this comment.

In regards to your point, checking the non nullness of the pointers passed is deliberate, as pretty much all the C string functions do not do such checks, except for those as part of Annex K. Annex K is viewed by most as mostly ridiculous, because a null check still won't tell you if it's safe to write to, because it could be pointing anywhere.

In this case, it's also more than the failure condition, as the pointers from malloc would be assigned there as well. Proper usage for asprintf() should always follow the idiom of a local char * passed by address to the function.

If for your own needs you agree with the design of Annex K, and want such checks, by all means, add an if around the entire body of the function to do nothing but return -1 on failure, and perhaps set errno to EINVAL.