Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Sunday December 21 2014, @04:54PM   Printer-friendly
from the show-stopper-or-rare-event? dept.

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.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by VLM on Sunday December 21 2014, @09:16PM

    by VLM (445) Subscriber Badge on Sunday December 21 2014, @09:16PM (#128124)

    Maybe the solution is...OH I don't know...a simple init system, doing what an init system is intended to do, and doing it well?

    Some of the PR about boot times is weird.

    So the problem is that sysv init takes 50 million machine cycles to boot and a massive reimplementation of everything will "solve all our boot time problems" at the mere cost of zillions of sysadmin hours cleaning up the bugs in a new system. Unfortunately 50M machine cycles was "kinda slow" on my first 40 MHz 386 in '93 taking a bit over a second, but on a 3 ghz machine its best measured in microseconds, so a complete rewrite to make things faster seems kinda a waste of everyone's time. What with the conversion from spinning hds to ssds, and images connected to giant NAS machines, the boot time aspect just doesn't matter anymore. You could run sysvinit ten times and it would still be faster than sysvinit a decade ago because "hardware" so everything you did a decade ago will work now.

    By analogy you could create the worlds fastest "hello_world.c" as an exercise, but once its faster than your eyes can see it run, who cares? Or video game rendering framerates (far) above 60 hz when the physical LCD hardware can't update faster than 60 hz or so anyway, just no point.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2