Systemd catches up with bind events

Posted Nov 13, 2020 21:15 UTC (Fri) by willy (subscriber, #9762)
In reply to: Systemd catches up with bind events by MatejLach
Parent article: Systemd catches up with bind events

Said choice words being caused by systemd coopting a kernel boot parameter for its own purposes. Again, systemd not playing well with others.

to post comments

Systemd catches up with bind events

Posted Nov 13, 2020 22:20 UTC (Fri) by MatejLach (guest, #84942) [Link] (5 responses)

In this case it seems to be the kernel not playing well with others. Or rather not adhering to its own rules.

Which is precisely the point, cooperation rather than pointing the fingers would help here.

systemd has proven itself useful enough where it should be consulted by kernel developers and vice versa.

Systemd catches up with bind events

Posted Nov 14, 2020 0:49 UTC (Sat) by gerdesj (subscriber, #5446) [Link] (4 responses)

It doesn't matter who is right or wrong. As my parents used to say "six of one and half a dozen of the other".

The kernel by definition is used on all Linux boxes and systemd is probably by now the most widely used init system at least on systems that the sysadmin/user actually cares what is happening.

systemd has become the de-facto Linux init system or PID1 or whatever the hell you want to call it. I still recall coming across M van S's comments in init scripts for the first time rather a long time ago and suddenly feeling that a real person actually cared about me and my little system. I "got" open source about then - I kept on finding notes in man pages and readme files and so on that indicated I was dealing with people who give a shit. Every now and then I still find something to make me smile in a readme or a help menu. I don't get that feeling when I'm fiddling with Windows or Macs. Linux is properly corporate these days and quite rightly so - we've grown up but it is still nice to see a human touch sometimes.

Please remember why we do this stuff.

Systemd catches up with bind events

Posted Nov 21, 2020 6:59 UTC (Sat) by ras (subscriber, #33059) [Link] (1 responses)

> systemd has become the de-facto Linux init system or PID1 or whatever the hell you want to call it.

Only for the desktop distro's. It's too heavyweight for the smaller ones like Apline, OpenWRT or Android, containers like Docker don't use an init system at all. And that could well cover the bulk of deployed Linux instances.

Systemd catches up with bind events

Posted Nov 21, 2020 12:32 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

> Only for the desktop distro's. It's too heavyweight for the smaller ones like Apline, OpenWRT or Android, containers like Docker don't use an init system at all.

The vast majority of Linux distros including RHEL, SLES, Debian etc (not just the desktop ones) use systemd by default. Docker containers are not comparable to distros but some of them do run a init system and it is popular enough that several distros include a systemd-container package specifically for this purpose and systemd is not limited to a init system, so other parts gets routinely used in containers as well.

Systemd catches up with bind events

Posted Nov 23, 2020 13:29 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

> Please remember why we do this stuff.

It's hard to tell corporate types to remember FOSS had a human element when they came from outside that culture entirely, their salary depends on gentrifying it out of existence, and in their off-time their hobby is talking over everyone to proclaim “Well Actually everyone uses our software because our software is great because everyone uses it”.

Most of the interesting people seem to be using BSD these days.

Systemd catches up with bind events

Posted Nov 23, 2020 16:18 UTC (Mon) by anselm (subscriber, #2796) [Link]

Most of the interesting people seem to be using BSD these days.

It used to be that using Linux was the way to stand out from the crowd, to be nerdy and interesting and metaphorically show the finger to those stodgy Windows and Mac users.

Now Linux has been mainstream for a while and is no longer good for nerd cred. People's elderly relations can (and do) use it. This means that the people who were using Linux 20+ years ago, when it meant not being able to do certain things (that when pointed out, one would adamantly insist weren't worth doing, anyway), spending three days to get a new video card/monitor working, etc., are being forced into BSD if they still want to impress their peers. But that's not because of BSD's versatility, wide compatibility with popular hardware and peripherals, and technical excellence – it's because few other people want to use it. It's the IT equivalent of an Indian fakir's bed of nails; very comfortable and just the thing if you're a fakir, but an item of morbid fascination for others.

Systemd catches up with bind events

Posted Nov 14, 2020 0:03 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (2 responses)

No, the parent comment is right. The issue was caused by: 1) a distro backport to systemd that had a bug, which caused it to spit too much debugging output, which caused it to timeout because the framebuffer console is insanely slow; 2) kernel developers spending more time crafting flaming emails than looking 1 inch further than their nose.

Come on, even Linus said that it was perfectly fine for systemd to use the command line that way[1] and, after having laced some emails with remarks about Kay, later admitted that it was just a bug and people were overreacting[2].

[1] http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01488.html

[2] http://lkml.iu.edu/hypermail/linux/kernel/1404.0/02712.html

Systemd catches up with bind events

Posted Nov 16, 2020 0:20 UTC (Mon) by nevets (subscriber, #11875) [Link] (1 responses)

It wasn't really the command line usage that was the problem. The real problem was that the command line triggered systemd to spam the kernel printk buffer so much that we lost all debug messages from the kernel. When reporting this as a problem, instead of saying there was a bug in systemd, we were told it was not a bug and systemd is perfectly fine using the debug command line to trigger writing debug messages in the kernel printk buffer. I thought the real solution was to separate kernel writes into printk from userspace writes, preventing userspace from overwriting what the kernel produces.

This would not have escalated the way it did if we were told from the beginning, "oh there's a bug in systemd that causes it to spam the buffer, please upgrade to a fixed version". But instead told to bugger off. Yes, it really is a lack of communication and good faith between the two communities and I hope we can work better in the future.

Systemd catches up with bind events

Posted Nov 16, 2020 7:55 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

> oh there's a bug in systemd that causes it to spam the buffer, please upgrade to a fixed version

Technically the upstream people couldn't have known, since the bug was introduced by an incorrect distro backport. And if a buggy systemd, one that spews assertion failures all the time, will slow boot down to a crawl, the systemd people might even consider that to be a feature. It can and will happen for kernel WARNs as well, and a buggy PID 1 is not much better than a buggy kernel. But these are details, and in general I think we agree.

What this shows to me, is that Linux is sorely lacking postmortems. Whenever Linus screams at me, I try to figure out what went wrong in my workflow and how I can improve it to avoid being screamed at in the future. On the other hand, if 5 years later people still believe that "debug" is a sacred part of the kernel command line (and not the more nuanced explanation that you gave), something went wrong on the kernel side in figuring out what happened.

Systemd catches up with bind events

Posted Nov 14, 2020 0:39 UTC (Sat) by foom (subscriber, #14868) [Link] (2 responses)

"You can't use the boot command line option 'debug', it's ALL MINE!"...Seriously? "Coopting"?

As a user, I'm sure I don't really care which part of the system boot is implemented by code in the kernel and which is implemented in systemd/udev/etc. I just want them to work together to boot the system properly. I mean, it makes sense to me that if I want to debug an issue, that everyone would respond to the one debug flag...

And same for "This incompatibility is all their fault!" -- again...who cares? It's nonsense.

Systemd catches up with bind events

Posted Nov 14, 2020 13:30 UTC (Sat) by willy (subscriber, #9762) [Link] (1 responses)

Uh, yes, "coopting".

"divert to or use in a role different from the usual or original one"

What word would you use to describe using something for your own purposes that somebody else was already using? It's not like I said "stealing".

Systemd catches up with bind events

Posted Nov 14, 2020 16:26 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

When you say "the original purpose" of /proc/cmdline and the debug flag, do you mean "System services are *supposed* to parse it, because it gives a unified way for people to pass in various flags. The kernel doesn't complain about flags it doesn't recognize, exactly because the kernel realizes that "hey, maybe this flag is for something else". The classic example of this is things like "charset" markers, but also options to modules that modprobe parses etc etc. And yes, that does include "quiet" and "debug"."?