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: 2) by maxwell demon on Sunday December 21 2014, @08:03PM
Did you actually read the post I replied to?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by fnj on Sunday December 21 2014, @08:22PM
Yes, actually, I did. What caused you to leap to "So the tools don't allow to pipe the output to tail or grep?" Because journalctl fully allows such piping.
(Score: 2) by maxwell demon on Sunday December 21 2014, @08:42PM
This:
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Sunday December 21 2014, @11:45PM
journalctl -b -u ntpd.service | grep waking
Dec 19 00:51:57 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 19 00:51:59 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 19 17:07:45 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 20 00:19:19 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 20 07:53:49 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 20 07:53:51 wheatley ntpd[1765]: new interface(s) found: waking up resolver
Dec 21 17:49:27 wheatley ntpd[1765]: new interface(s) found: waking up resolver
I don't see the problem, here.
(Score: 0) by Anonymous Coward on Monday December 22 2014, @12:07AM
let me correct that for you.
journalctl -b -u ntpd.service | grep waking
journalctl: log corrupted.
because they refuse to fix the automatic log corruption if you turn on log rotation.
(Score: 2) by tempest on Monday December 22 2014, @12:11AM
Wow... Fuck.
(Score: 3, Insightful) by Anonymous Coward on Monday December 22 2014, @12:36AM
I'll highlight the problems for you:
The first problem I see is that you need to use journalctl. It should never be a requirement that a log file be filtered through some program before grep can work with it.
The second problem I see is that some of the lines are out of order. I don't know if the timestamps are wrong, or if they were logged in the wrong order, or if journalctl screwed them up, but clearly some are where they don't belong.
The third problem I see is the random binary data at the end of some of the lines. That probably should not be there as far as I can tell.