SystemD failure highlights, and evation notes for Debian users

Owned by Christoph Lechleitner
Last updated: 2018-08-10Version comment

Motivation: Failure highlights (Why I don't like SystemD)

Recently almost every distribution started switching to systemd as init replacement, including the upcoming Debian release, jessie.

Also, Gnome3 and other tools depend on systemd via logind or the like.

While I agree that the process management of systemd is wonderful and clearly beats sysvinit, systemd has some issues that are not yet been really dealt with:

  • Services (daemons) that have stopped (or even didn't really come up) are still reported as OK, i.e. postgresql on jessie. Huge Blocker.
  • Behavoural changes and option incompatiblities, to commands that have not changed in ages, like:
    • shutdown: systemd's shutdown does not support -t anymore and tends to wait 5 minutes - without a 100% correct double-fork bzw. Big Blocker.
    • OpenVZ guests' networking fails to come up if guest uses systemd. Blocker. 
  • Failure to shut system down (power not switched off), on 5 of 5 systems I tried (2 ThinkPads, 3 Desktops). Blocker.
  • Major bugs the project "gurus" refused to solve, like:
    • Picking up the kernel command line parameter "debug", sometime followed by a crash due to the amount of log data created. Half solved, see freedesktop bug #76935. Former Blocker.
    • Binary logs without transaction protection, leading to broken logs sometimes. Blocker. 
  • SystemD uses Google's name servers and even their leap-smearing time servers by default. Bad Joke.
  • Structural disadvantages, like:
    • Too many things run in PID 1, for sure more then necessary. Bad design.
    • All things in one (debian) source package (see packages.debian.org/source/jessie/systemd), so everytime any of those is updated, there's a chance the init process (PID 1) must be reloaded in-place, risking severe and total system corruption every single time. Inconvenient design.
  • Uncommented automatic upgrades on startup and daily,, on a screenless virtualized server WTF.
    Solution: systemctl disable apt-daily-upgrade.timer apt-daily.timer ; systemctl stop apt-daily-upgrade.timer apt-daily.timer

Yes, PID 1 code and PID 1 reloading are being tested a lot, but considering the damage a single once-in-a-milllion incident can do, that's ...

Too much for my own taste, especially for servers running 24x7 services, particularily for Virtual Root hosting like OpenVZ on which we rely for almost everything.

Long-term solution: Maturation, hopefully

I assume the issues mentioned above will be dealt with in the mid to far future, because over time "enough" incidents will occur ...

Mid-term solutions: Devuan and/or uselessd, ...

Several projects try to solve this painful situation:

  • Devuan.org, a Debian fork beeing set up by Veteran Unix Admins (like me), hence the "vua"
  • Uselessd, a systemd fork trying to solve

Short-term solution: Jessie without SystemD

Upgrading from wheezy to jessie without pulling in systemd

Not sure yet. Perhaps blocking systemd with a pin priority of -1 (see below) before the dist-upgrade is all that's needed. Input welcome.

Getting rid of installed systemd components

# Approach:
# 1. install replacements for things to remove
# 2. remove any package depending on systemd or containing "systemd"
#    Exception: libsystemd0. This only seems to contain functions for software that optionally can use systemd.

apt-get install sysvinit-core
 
# recommend to reboot, because removing systemd while it's the active init system usually fails
reboot

# remove the "evil"
# on some of my systems this removed xfce4, vlc, ..., not sure why, I was able re-install most of those
apt-get remove systemd libsystemd-journal0 systemd-shim
 
# check for other systemd packages
dpkg -l |grep systemd |grep -v libsystemd0
 
# evtl. get rid of things that are not required any more
apt-get autoremove

Preventing unintentional systemd re-installation through dependencies

To prevent "Recommendations" from beeing treated as dependencies, edit an existing /etc/apt/apt.conf.d/99synaptic, or create some /etc/apt/apt.conf.d/999_suppress_install-recommends to contain this:

APT::Install-Recommends "false";
 
# or simple
echo 'APT::Install-Recommends "false";' >>/etc/apt/apt.conf.d/999_suppress_install-recommends

To block systemd 100%, specify a negativ pin priority in /etc/apt/preferences.d/pin:

Package: systemd
Pin: release *
Pin-Priority: -1

If you have are make multiple entries, don't forget to separate each paragraphs with an empty line.

Display managers not depending on systemd

To get a full list call   apt-cache showpkg x-display-manager   and look below "Reverse Provides:".

  • xdm. The original display manager. Doesn't even allow to choose among installed window managers
  • wdm. (WINGs display manager). Like xdm in WindowMaker style, with window manager selection, but no locale selection.
  • slim. Really slim, F1 rotates through available sessions (window managers)
  • lightdm. Allows to choose window manager and locale. Pulls in libpam-systemd but allows to remove it afterwards.
  • "startx". Not a display manager of course, but in some setups one doesn't need a display manager.

Window managers not depending on systemd

  • xfce4 (screenshots), my favourite. But there are add-ons, namely xfce4-power-manager, that depend on systemd
  • openbox (screenshots). Rudimentary but may all one needs. Comes without a taskbar but supports others like xfce4-panel.

A long list of window managers can be found at http://www.gilesorr.com/wm/table.html.

Network managers not depending on systemd

  • wicd, with wicd-gtk or wicd-kde as frontend manages LAN and WLAN connections ok.
  • wvdial was always my favourite for dial-up connectivity

Other app alternatives

  • FIle managers with SFTP integration: Use sshfs.

Further remarks

To be continued ...

Further links