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.
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.