Linux kernel hacker's open rant about systemd

by
in linux on (#3V8)
Linux kernel hacker Christopher Barry has engaged a full frontal assault of the systemd Linux subsystem and its creator, Lennart Poettering, on an "Open Letter to the Linux world" published on the Linux kernel hackers' mailing list. Here's a taste:
So why would very smart people who love and use Linux want to create or embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the reasons they say, as I mentioned at the top. But partially I think it's from a lack of experience. Not a lack as in programming hours, but a lack as in time on the Planet. Intelligence alone is not a substitute for life experience and, yes I'll say it, wisdom. There's no manual for wisdom. Implementing systemd by distros is not a wise move for them over the long term. It will, in fact, be their ultimate undoing.
Systemd has been no stranger to controversy. It broke a lot of systems, and important figures in the Linux world have registered their doubt about the replacement to the well-known System V init system, which was a fully transparent collection of human-readable scripts but that led to slow boot times. It will be interesting to see if Barry's rant generates a groundswell of antagonism against the new system, or if it gets ignored, or if it leads to meaningful debate and change.

[Ed. note: picked up this story from comp.misc. Thanks, Rich!]
Reply 8 comments

sysvinit was a dead end (Score: 4, Insightful)

by mth@pipedot.org on 2014-08-14 00:53 (#3VA)

I'm not a big fan of systemd, but I disagree with the idea that sysvinit didn't need replacement.

It required a large amount of boilerplate in the service start/stop script, which was different between distros, making it a lot of work to provide a decent start/stop script for your daemon. The hard work of distro maintainers hid this nuisance from most end users though.

Ordering the service startup sequence by manually assigning priorities to them (S80myservice) instead of using dependencies is a terrible hack. It also prevents services from being started in parallel, which is a pity on today's multi-core systems. It's like building your code using a shell script instead of a Makefile.

There is no consistency in how services are started: inittab can respawn, init.d scripts can query the service status (on some distros!), (x)inetd can start services on demand, but all have different configurations.

I have some doubts systemd is the right solution to these problems, but at least there is movement now. In my opinion, the solution would be to improve systemd or replace it with something better, not going back to sysvinit.

Re: sysvinit was a dead end (Score: 1)

by nightsky30@pipedot.org on 2014-08-14 12:00 (#3VD)

I agree, the road ahead may be a little bumpy, but the movement forward is better than ending back at where we started. That service startup sequence was a pain in the ass.

Re: sysvinit was a dead end (Score: 0)

by Anonymous Coward on 2014-08-14 13:18 (#3VE)

I agree that we can do better than init for machines destined for desktop use: I'm a big Linux fan but I also appreciate the fast start-up time of my chromebook and my Mac, and Linux and BSD are both much slower. On servers though, I'd like to keep init, thank you very much - it's slow but I only reboot every six months or so, and in the meantime the clear, understandable, human-readable init scripts are lovely.

Maybe this is a more useful argument/discussion when we are careful to separate out Linux on the server vs Linux on the desktop?

Re: sysvinit was a dead end (Score: 2, Insightful)

by zocalo@pipedot.org on 2014-08-14 16:03 (#3VF)

Pretty much echoes my sentiments regarding SysVinit. It gets the job done with minimal resources, but it's not really appropriate for modern systems where a parallel and dependency driven init process is a major user requirement and resources are no longer an issue - especially on desktop and mobile devices where the user would like as near to instant on as possible. Despite that I find SystemD does what it is supposed to without too much fuss, and is in many ways more capable than sysvinit, I also think it's a bloated mess that was badly designed from the start, and when it comes unstuck fixing it is an absolute nightmare. Don't even get me started on the whole DBus integration/requirement thing; that sounds more like something Microsoft would have cooked up for Windows than the core principles of UNIX, and is one of the main reasons that I'm taking a good look at migrating as many of our Linux servers over to BSD as possible when they are next due for a refresh.

PID1 needs to just do the essentials and be a minimal piece of code that is pretty much as close to "hello world" as you can get to avoid complications and failures, everything else should either be an optional SystemD module or an external program depending on the the user's preference. Want SystemD to handle your logging, fine, tell it to load that module and off you go. Want to run a proper daemon that can listen for remote log entries too, then disable the SystemD module and use RSyslog or whatever you prefer. Some functions of SystemD are already modular, but that needs to go a lot further in my view, and requiring stuff like DBUS integration right there in PID1 is just asking for all sorts of stability problems, but it into a module, then at least there's a chance the system might be able to recover without a kernel panic.

It's fine (Score: 2, Interesting)

by skarjak@pipedot.org on 2014-08-14 02:36 (#3VB)

Archlinux made the switch to systemd something like two years ago. At the time, there was much complaining (and I was one of the people bitching), but I have to say now that it does the job. It hasn't caused me issues, and it's not that difficult to learn how to use it. People using other distros don't have to be worried, I think.

This rant will change nothing. Plenty of people have complained about systemd, but its advantages end up winning people over once the change has settled in. As the distros adopt it, we'll see users "revolt", then cool down after a while just like for archlinux Debian adopting systemd pretty much means that it's the way of the future.

Let's not forget also that Linux users are quick to complain about change (see: unity, kde4, gnome3). It's understandable: people don't want their workflow to be affected. I think it won't take too much playing around with systemd for most people to feel confortable with it.

Re: It's fine (Score: 0)

by Anonymous Coward on 2014-08-14 10:42 (#3VC)

What advantages does systemd have exactly? Almost everything new in systemd had already been solved in a a more sane fashion elsewhere. All it's done for me is break stuff that I wouldn't even think to check because... "an init wouldn't do that". More the fool me for thinking systemd was an init system rather than some bloated POS parasite with tentacles reaching every corner of the OS. The icing on the cake is that every critique on basic design or suitable functionality for an init system is met by the developers with a "because fuck you!".

This rant is just a rant (Score: 2, Insightful)

by Anonymous Coward on 2014-08-14 21:00 (#3VJ)

It's mostly sentimental, not much information in it. However, there are legitimate reasons to why systemd sucks. First of all, it was designed with the wrong goal. It tries to emulate the Windows services framework and fails badly. In the Windows world, a service conforms to a published (and even maybe stable) API. I don't know much about it but I would guess that it contains mechanisms to stop, restart and indicate success/failure. Everything systemd is trying to emulate with signals, polling etc. It doesn't work so well. Sometimes a server has a fatal flaw in it (or its configuration) and has no way of indicating "I'm no longer functional, don't restart me". So systemd tries to restart it and all its dependencies on and on, wasting my time. If it was intended to be a boot-time tool only, it wouldn't get so bloated and get in the way.

Second, it carries on the idea of 'file system is a configuration file' mentality. It did work for the SysV-init because that system was already very simple and was easy to discover. Not so with the systemd, you need to create your 'script' in a particular folder, link to it from the things which depend on it, and then do some more soft linking in order to start its dependent services. It's so complicated and undocumented, makes me wonder whether these guys know how to program at all. I mean, just parse a fucking config file for dependencies, what's so hard about it?

Which brings me to the third point. The alleged "eases developers' job" applies only to RedHat developers, not the guys who write the actual servers being run or the users who want to get out of the distribution's boundaries. The whole thing only works if you use your system in the way your distributor intended for you to do. This of course eases the work of RedHat developers since they don't have to deal with silly things like documentation, stable design etc.

On the computer I had before this one, I had sysv-init. I had reduced the whole thing into inittab + one script since I didn't have anything complicated on it. Of course it booted blazingly fast since it didn't need to read hundreds of mini config files. I couldn't do it starting from systemd. Everything is spread around in so many files (and so many soft links), it's impossible for me to wrap my head around.

I do think that sysv-init could be replaced with something better but systemd isn't it. Something which can read a configuration file and start processes (not services, eww) in parallel would be a way forward. There is a lot more to talk about how systemd fails and I'm sure many people have done a more thorough job elsewhere but this is just my two cents.

Re: This rant is just a rant (Score: 0)

by Anonymous Coward on 2014-08-15 10:28 (#3VW)

Mod parent up!