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.
For every bug report, thousands are affected. (Score:4, Insightful)
There's a maxim in software testing that goes like, "For every user who reports a bug, there are thousands of affected users who didn't report it."
I think that's exactly what we're seeing with systemd. Thousands and thousands and thousands of people are getting fucked by it and its numerous flaws. That's why it's such a controversial subject. Yet only a very small fraction of these people ever both to report these systemd bugs.
The rest of us don't bother, because we're moving on to Slackware, or FreeBSD, or OS X, or even Windows. We're done with Linux. Why should we waste our time reporting bugs with software we didn't want to ever use in the first place, and will likely never use ever again?
So when I see two bug reports, I know that realistically, we're talking about probably 20,000 to 50,000, if not more, users who experienced the same problem. That's a serious issue, if you ask me.
Re:For every bug report, thousands are affected. (Score:4, Funny)
Making a public pledge to no longer contribute to that other place, whatever it was called
Parent
Re:For every bug report, thousands are affected. (Score:5, Insightful)
I think that's the difference and crux of the problem right there. The systemd team have demonstrated more than once that they regard fixing bugs in their code as either someone else's problem or not as important as adding the next great feature. That's not a problem unique to systemd (far from it), but with systemd it is in one of the few places where you simply can't afford to have that kind of attitude - another being the kernel itself. It's an approach leads to code that has more than a passing resemblance to a house of cards, and when that particular house of cards is also the foundation upon which other projects sit things you are risking the whole lot coming crashing down.
UNIX? They're not even circumcised! Savages!
Parent
Come on, Debian. Systemd needs to go! (Score:0)
I just can't understand why Debian is still going forward with systemd. How many more of these idiotic, unacceptable problems will there need to be before it's removed?
At this point, I think it'd be perfectly appropriate to postpone Jessie until systemd can be removed. Get rid of it, and start the Jessie stabilization process from scratch. If that means the release is delayed for months or years, so be it. It's just the right thing to do.
Re:Come on, Debian. Systemd needs to go! (Score:4, Insightful)
> I just can't understand why Debian is still going forward with systemd. How many more of these idiotic, unacceptable problems will there need to be before it's removed?
Perhaps you are misunderstanding their motives. You think "If I were doing this, I would want to produce a quality product." and so you assume they think the same. In your world, once they finally understand the error of their ways, they would repent and sin no more, even if it meant throwing out years of wasted (if shoddy) work.
Imagine someone whose internal thoughts instead go like this: "Sure there are problems here and there, but I'm going to plow ahead anyway." What is that person's motivation?
Now you start to understand what we're up against.
Six out of ten say they don't like Clinton OR Trump. If ever there was a year to vote third-party, this is it.
Parent
Thanks for the warning! (Score:0)
I'm grateful that SN keeps posting these systemd stories. They've helped me avoid a lot of problems so far. I was going to upgrade my Fedora 20 system later today oddly enough, but I won't risk it now that I know about this problem. I don't read about these systemd problems at other news sites, so I'm relying on SN to keep me informed. Please keep putting these stories on the front page! They keep saving my ass!
Why are rare bugs less important? (Score:0)
A bug that affects even just one user is as important as a bug that affects thousands of users, or even millions of users. It's easy to say, "It's one user!" when you aren't the one affected, but your attitude will quickly change when you are the person suffering from the bug's effects!
You won't be saying it's a "rare fault" when it's your Fedora system that no longer works because systemd crashed during the upgrade, ruining the system!
Rare bugs aren't less important. They're just as important as any other bug. And they should be fixed quickly, not years later, or even never!
Re:Why are rare bugs less important? (Score:4, Insightful)
Now hold on, hear me out.
The thing is, the two problems that he mentions are not just bugs. They are bugs, but they are not JUST bugs. If they were just bugs, it would be a minor annoyance.
What makes them critical show-stoppers, not just minor annoyances, is the flawed systemd *design*. Most programs can throw a page fault now and then, and we wont mind. Just as long as it's not PID1. Better to put something with a simple, robust design in PID 1 than to bother fixing the bug at issue.
And the second - the poor log interface. Again, on a sane system that would not be any more than a minor annoyance. So the log viewer sucks, what did you expect? Close it and open the logs with your choice of text editor, doh. It's the bad design choice of using a binary log file that makes this minor annoyance into a show-stopper bug.
So, fix the *problems* yes, but don't fix these particular *bugs*. Because as long as you stick with this fundamentally wrong-headed design, minor bugs will continue to turn into show-stoppers on a regular basis.
Friends dont let friend enable ecmascript.
Parent
Re:Why are rare bugs less important? (Score:4, Interesting)
So these bugs are just symptoms of the greater bug, which is that systemd is fundamentally broken
Yes AC you are basically correct although a little vague. The fundamental brokenness is in the design. If they scrap this batch of code and start over, they'll end up with another steaming pile equivalent to this one, because (follow the money) their core philosophy is wrong. Nobody wants to turn linux into a gnome desktop bootloader except people paid to do exactly that. Nobody wants to bring windows software development architecture (weakly interacting massive programs, inner platform effect taken to an extreme, who cares about security or debugging all that matters is feature-lists, etc) into linux except people paid to do it. The recent success is due to product tying, so the only hope of linux survival is simply to drop gnome, or whatever else gets product-tied in.
I escaped and get to laugh from the freebsd equipped sidelines so I don't have a dog in the fight anymore, although the savage destruction is sad to behold.
Parent
Serious? (Score:2)
Both of these behaviors contribute to making the tool much less usable, especially in critical situations where time and efficiency are of the essence.
I'm sorry, but I'm having a difficult time seeing how poorly formatted logs become serious, even in a supposed "critical situation". It's an inconvenience, and you may lose a little more time scrolling through everything to find what you're looking for, but it's hardly the disaster being connoted.
I'm personally undecided about the whole systemd issue. There are things about it that I actually kind of like, and the disadvantages I've heard about so far don't really affect me. I've certainly not had the trouble that people are supposed to be having. I think part of the problem, in addition to the editor's comment about bug reports being a rarity, is that so often the people who complain loudest about systemd have the attitude of, "OMG! Dis iz da worst ting ever!! It must be fixed naaaooo!!!!!1!!1!" At least it seems that way to me sometimes. It'd be refreshing to sit down and discuss seriously the pros and cons, and figure out how to improve, or if necessary, replace, systemd. And it would be done in a way where someone's thoughts aren't completely written off simply because they think there is a benefit (or disadvantage) to the software as it stands now. There does seem to be some serious resistance from some of the key decision makers in addressing its issues, though, and that is a problem too.
Re:Serious? (Score:4, Insightful)
So the tools don't allow to pipe the output to tail or grep? Then that is the real problem, not overly long log lines or too long logs.
The Tao of math: The numbers you can count are not the real numbers.
Parent
Re:Serious? (Score:5, Insightful)
Friends dont let friend enable ecmascript.
Parent
Re:Serious? (Score:4, Insightful)
Oh, look, that assumes that you booted correctly.
This is a system designed to fail just when it is needed most. When the system is working fine, you can export the logs that show it working fine, but when it fails and you really need to see those logs, you cannot.
Friends dont let friend enable ecmascript.
Parent
It's (supposedly) an init system (Score:3, Interesting)
There have been several posts here about the relative importance of bugs...some I've already replied to.
It almost seems as though people are forgetting this this is (or is supposed to be) first and foremost, and init system. What bugs aren't important in an init system? Are "rare" bugs (translated: bugs of frighteningly unknown origin) somehow not important?? 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?
Attacks originating in ignorance (Score:4, Interesting)
FTFS:
Not a systemd advocate here, but that is a question of familiarity with the tools, which is to say willingness to learn. The author whose article is being summarized, did not try very hard. In fact, I would say he is not much of a Unix user in spirit. Try "man journalctl" sometime. You will see stuff like:
"-b [ID][±offset], --boot=[ID][±offset] Show messages from a specific boot. This will add a match for "_BOOT_ID="."
How do you do that when not using systemd? Hmmm?
"-- no-full 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."
That is more control than you get with "less /var/log/messages".
"-n, --lines Show the most recent journal events and limit the number of events shown. If --follow is used, this option is implied. The argument is a positive integer or "all" to disable line limiting. The default value is 10 if no argument is given."
That gives you recent lines at least as easily as using tail, or feeding options to less, does.
"-r, --reverse Reverse output so that the newest entries are displayed first."
I'll leave that as an exercise for you to figure out when not using journalctl - have a ball.
"--since=, --until= Start showing entries on or newer than the specified date[/time], or on or older than the specified date[/time], respectively."
I'd say that is a lot more straightforward than doing similar selections without using journalctl.
There is a lot more; journalctl has an incredibly rich set of options, and you can pipe it to use your favorite traditional tools too. The claim that journalctl "displays all messages since the beginning of time" is just ignorant.
So in summary, out of fairness, I am calling utter bullshit.
re Wondering (Score:2)
I been wondering, why all major (almost all, anyway) Linux distros changed to systemd?
I'll give you my conspiracy theory: some key people in there are being funded my Microsoft!
When your upgrade is as iffy as a Windows upgrade, you have to concede that someone from *that* camp has crossed over and messed things up.
Maybe it is non-sense, but I really wonder why stable distros have choosen uncertainty and chaos when the bedrock foundation of Linux was robustness; not ease of use or click-next to install, but rock solid performance year after year. Why?
If someone knows why, please share with the unwashed...