RogerBW's Blog

Farewell to systemd 22 May 2016

I tried to give it a fair shake. Really I did. But systemd has now annoyed me to the point where I've been removing it from the systems for which I'm responsible and bringing back sysvinit.

Mostly it was annoying rather than problematic, at first. Oh, you asked for log output? I'll only ever show you the first fifty characters of each line, unless you expand your terminal to take up the whole screen. Only losers would ever want to grep logfiles, so I'll do that job for you, only in a less powerful way. Did a daemon fail during startup? I'll hide those logs away in my own special store separate from the main logs, and show you only the last couple of lines because you don't need to see any more.

Then I found system upgrades hanging on daemon restart, first on one machine, then on two others. This turned out to be because systemctl (after doing the restart) was spawning a systemd-tty-ask process to ask for a password. No password was wanted, there was nothing in the configuration to say it would be wanted, but off it went anyway. And didn't in fact ask for a password or do anything else, apart from sitting there.

I asked a reasonably competent technical community about this, and the one useful answer I got was "file a bug against systemd". Yeah, thanks, that really helps. If you guys can't fix this…

Sometimes it does this while stopping a service, for example when you're rebooting. Because it's obviously ideal to have a machine hang forever in a state where no external access is possible. (A note to people running Windows: most computers don't actually do this.)

Then there have been various mount issues. If you bind-mount a filesystem (e.g. for a chroot), if systemd was involved, when you unmount that bind the main filesystem gets unmounted too. You weren't using /dev for anything, were you? According to this bug report, this is correct behaviour and all other software is wrong.

It lies about whether daemons are running, the thing it's supposed to be really great at. It'll claim something's running when it actually crashed on launch, or that it's failed when it's actually running quite happily.

And I have one server with a /storage filesystem which should be automounted, but isn't essential to boot. With sysvinit, it just works. systemd claims it timed out (even though it works perfectly if mounted from the command line), won't give me any more details, and won't carry on the boot process to give me an ssh server to get in and fix it. Apparently there's a special new magic keyword you can put in fstab to stop it doing this and make it behave like every other system.

Did you like the -F option to shutdown ("force a fsck on reboot")? It's gone away with systemd, because it works by writing a /forcefsck file to the root of the filesystem; it has been declared that if you think your filesystem might be dodgy, you shouldn't be writing to it. (Which is somewhat true.) And that that is the only reason you might ever want to force a fsck. (Hint: it isn't.) And systemd people know better than you what you should be allowed to do on your system.

People keep saying systemd is great. Debian developers had a long and acrimonious discussion over it. Having real boot dependencies is a really nice idea; ditto faster boots, though reboots are rare (or damned well should be). What I want a boot process to do is give me an ssh server if it possibly can, whatever else may have broken, because I don't only run Linux on the desktop; I run it in datacentres in multiple countries, and I can't casually hop on a plane to plug in a screen and keyboard to go and fix it. Having a consistent execution environment for daemons is great too, but is it worth all this faff? Not for me.

The real problem is that systemd wants to do everything, in its own way. It's not just a service manager, it takes over your log files too. And it wants to control network interfaces, because they could be part of the boot process, right? And… if I wanted a monolithic system that did everything where I couldn't get at it to make it work the way I want it to work, I'd be running Windows.

I'm sure this thing offers some benefits to some people, especially desktop users who actually turn off their machines, but for me the cost in extra effort and things randomly stopping working is too high.


  1. Posted by Owen Smith at 02:47pm on 22 May 2016

    I hear a lot of negative things about systemd at work among the unix guys. Admittedly most of them have been using unix at least as long as you have Roger so it may be they don't like change. But like you several of them gave it a go and then ditched it. I hear there's a big argument going on in thr FreeBSD community about how much of this sort of thing it should be copying from Linux, I say none to give people an alternative.

    I have a Unbuntu machine on my desk, but it's a secondary machine for doing my compiles on. All my user interface to it is done using a Windows 7 mahine, the Ubuntu machine has no keyboard or monitor on it and all I do on it is ssh in with Putty to do compiles. I have no idea if it runs systemd. I leave both machines running all the time, it's not the time it takes them to boot it's how long it then takes me to reopen files in my editor, open Perforce in the right workspace, restart the debugger, etc. etc. The time saving of leaving everything running so I can pick up where I left off yeterday evening is considerable, and it also helps me remember what I was doing.

  2. Posted by RogerBW at 09:51pm on 22 May 2016

    If systemd isn't causing you any trouble, then that's fine. I'm still running it on the NUC that drives my projector, because there I do care about short boot times and I don't have much in the way of unusual daemons that need special handling. So the defaults work. I just find it a pain when I need to get my hands dirty.

  3. Posted by Owen Smith at 01:46pm on 23 May 2016

    So you're the one that bought an Intel NUC then.

  4. Posted by RogerBW at 02:09pm on 23 May 2016

    Have sales been bad? They seem to keep bringing out new models, and I know quite a few people who use them.

  5. Posted by Owen Smith at 05:05pm on 24 May 2016

    I just can't get over the silliness of the name, both the acronym and what it stands for. Pretentious or what.

  6. Posted by RogerBW at 05:36pm on 24 May 2016

    I always pronounce it "nuke". The pretentious types seem to prefer "N-U-C".

Comments on this post are now closed. If you have particular grounds for adding a late comment, comment on a more recent post quoting the URL of this one.

Search
Archive
Tags 1920s 1930s 1940s 1950s 1960s 1970s 1980s 1990s 2000s 2010s 2300ad 3d printing action advent of code aeronautics aikakirja anecdote animation anime army astronomy audio audio tech base commerce battletech bayern beer boardgaming book of the week bookmonth chain of command children chris chronicle church of no redeeming virtues cold war comedy computing contemporary cornish smuggler cosmic encounter coup covid-19 crime crystal cthulhu eternal cycling dead of winter doctor who documentary drama driving drone ecchi economics en garde espionage essen 2015 essen 2016 essen 2017 essen 2018 essen 2019 essen 2022 essen 2023 essen 2024 existential risk falklands war fandom fanfic fantasy feminism film firefly first world war flash point flight simulation food garmin drive gazebo genesys geocaching geodata gin gkp gurps gurps 101 gus harpoon historical history horror hugo 2014 hugo 2015 hugo 2016 hugo 2017 hugo 2018 hugo 2019 hugo 2020 hugo 2021 hugo 2022 hugo 2023 hugo 2024 hugo-nebula reread in brief avoid instrumented life javascript julian simpson julie enfield kickstarter kotlin learn to play leaving earth linux liquor lovecraftiana lua mecha men with beards mpd museum music mystery naval noir non-fiction one for the brow opera parody paul temple perl perl weekly challenge photography podcast politics postscript powers prediction privacy project woolsack pyracantha python quantum rail raku ranting raspberry pi reading reading boardgames social real life restaurant reviews romance rpg a day rpgs ruby rust scala science fiction scythe second world war security shipwreck simutrans smartphone south atlantic war squaddies stationery steampunk stuarts suburbia superheroes suspense television the resistance the weekly challenge thirsty meeples thriller tin soldier torg toys trailers travel type 26 type 31 type 45 vietnam war war wargaming weather wives and sweethearts writing about writing x-wing young adult
Special All book reviews, All film reviews
Produced by aikakirja v0.1