Reply to post:

Linux greybeards release beta of systemd-free Debian fork

Ben Tasker Silver badge

> Most of the problems with systemd stem from not knowing or not caring about how to use it

I think that's a little unfair, but, that said, the very presence of systemd on a system can also lead to a systemd blinker coming down when troubleshooting.

I actually spent some time dealing with an issue earlier. For some reason systemd-udevd had started deciding to rename a NIC from it's configured name to "rename2".

I'm sure Lennart's ears were burning for a little while, until I looked a little closer and remembered what fuckwits Realtek are.

The NIC in question is part of a bond, and on the reboot just before the issue, systemd got impatient waiting for the network to come down cleanly, so just shut it off. On boot, the RTL driver reads the MAC from the NICs volatile storage (instead of the PHY) so got the bond's IP instead, which of course matches the other slave. So two NICs matched the same udev rule...oops

Blaming the (sometimes) clusterfuck that is systemd is too easy and rarely solves the problem itself.

But systemd isn't faultless either, just as some distros managed to ship flawed selinux configs (apache context? Nah, won't need /var/www/html). It's got it's problems and journalctl is a fair example (system hung and want to know why? Sorry the binary log is corrupted). Being able to pass through to rsyslogd is a bandaid not a fix for the issue

Or, as others have pointed out, the NTP issues.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019