Child pages
  • SystemD failure highlights, and evation notes for Debian users

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: WTF: apt-daily-upgrade

...

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

...