SoylentNews is people
SoylentNews
Noted Linux expert Chris Siebenmann has described two catastrophic failures involving systemd.
One of the problems he encountered with systemd became apparent during a disastrous upgrade of a system from Fedora 20 to Fedora 21. It involved PID 1 segfaulting during the upgrade process. He isn't the only victim to suffer from this type of bad experience, either. The bug report for this problem is still showing a status of NEW, nearly a month after it was opened.
The second problem with systemd that he describes involves the journalctl utility. It displays log messages with long lines in a way that requires sideways scrolling, as well as displaying all messages since the beginning of time, in forward chronological order. Both of these behaviors contribute to making the tool much less usable, especially in critical situations where time and efficiency are of the essence.
Problems like these raise some serious questions about systemd, and its suitability for use by major Linux distros like Fedora and Debian. How can systemd be used if it can segfault in such a way, or if the tools that are provided to assist with the recovery exhibit such counter-intuitive, if not outright useless, behavior?
Editor's Comment: I am not a supporter of systemd, but if there are only 2 such reported occurrences of this fault, as noted in one of the links, then perhaps it is not a widespread fault but actually a very rare one. This would certainly explain - although not justify - why there has been so little apparent interest being shown by the maintainers. Nevertheless, the fault should still be fixed.
(Score: 3, Insightful) by Foobar Bazbot on Monday December 22 2014, @06:52AM
Y'know, there's actually a pretty serious problem here, but I completely agree that it's not the problem the complainer thinks it is. Even if you can't be bothered to RTFM, when confronted with a utility outputting to a tty through a weirdly-behaving pager, the most obvious thing to try is not giving it a tty, e.g. journalctl | less, because any sane program checks if it's connected to a tty before doing weird tty stuff. Sure enough, that works -- journalctl dumps plain text to stdout, and less folds or chops long lines exactly as you told it to in your LESS environment variable.
No, the real problem is that journalctl (and other parts of the systemd ecosystem) takes it upon itself to provide "sane" defaults, and to provide a way to override those defaults -- all completely ignoring and overriding the existing configuration mechanism. In this case, it's journalctl feeding less a fistful of options to override the settings in your LESS environment variable (but you can override the override by setting SYSTEMD_LESS), but much the same thing is the cause of the Magic SysRq story.
And every time this happens, and someone complains, the systemd developers/enablers just can't see what their problem is -- after all, you can configure what setting systemd overrides the existing configuration with, and that should be enough for anyone!