Live data from Hacker News

Response to systemd's use of the debug flag

plus.google.com

31–36 of 36 posts

Re: Response to systemd's use of the debug flag

#31
post #28
post #17

> A kernel is just one component of the OS among many, and ultimately an implementation detail. -- Lennard Poettering

Uhm without Linux specific kernel details systemd would not exist. This as well as journalctl taking minutes to show logs after months of normal usage...systemd is out from my Arch.

May I suggest OpenRC:

http://blog.notfoss.com/posts/openrc-on-arch-linux/

Re: Response to systemd's use of the debug flag

#32
I am surprised by the hostility displayed by the systemd guys. I was expecting them to admit they were wrong, and things would be back on track.

With such a reply, I wonder what effect will this have on kdbus making forays into the kernel (not that I am looking forward to it ;).

Re: Response to systemd's use of the debug flag

#33
post #25

Earlier quoted context omitted.

> systemd can limit its own output and say "my bad"[This happened] Did it? I didn't find any such commit. IMHO it's the correct fix. /dev/kmsg is privileged and systemd should rate-limit what it writes there after giving priority to more critical messages.

I guess I phrased it wrong, I was referring to the bug fix that stopped systemd from all of the spam and not internal rate limiting.

Okay, I think 6a0f1f6d5af7c7300d3db7a0ba2b068f8abd222b "sd-event: rework API to support CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM, too" removed the dual_timestamp_is_set assert. It looks like it was fixed by accident, and there's zero acknowledgement that flooding /dev/kmsg could be a problem on systemd's side.

Re: Response to systemd's use of the debug flag

#34

I wonder how this whole thing would have gone down if the original bug report had simply described the problem rather than demanded their preferred solution to what they thought the problem was. Linus and others keep acting like the bug was "systemd floods the kernel logs when I pass the debug flag" but it was actually it was "Do not parse "debug" command line ". The obvious answer to the first is " Sorry about that,…

I think Linus has been pretty clear on both topics (fix A, and if you won't, fix B) and on general policy (don't break it for users or I don't want to work with you in the kernel). Yeah, the reporter could have framed it better from the start, but the developers are supposed to be adults and handle imperfect bug reports too.

FWIW, I don't really consider the first issue fixed. The trigger was lost in a refactoring that can't be backported, and there are probably other ways to trigger the issue.

Re: Response to systemd's use of the debug flag

#35
post #30
post #3

Hmm, I was expecting "Sorry we made a mistake, we'll switch the option to systemd.debug". > At that point there is simply no other option for that, because persistent storage is not available This was about overloading an already used option by another team building a core system component -- the kernel. A debug for kernel's command line is for the kernel. > It's the option an admin can specify which tells him why th…

>And did he just write that kernel is just "an implementation detail?". In theory, systemd could be made to work on BSDs, Hurd, Minix, or whatever. In reality, I'd sooner expect systemd to provide it's own kernel, but you never know.

The context for that remark is:

My system isn't booting. I don't know why. I'll pass "debug" to find out. Right here, and now, the fact is that the problem could be in many places inside or outside the kernel including (but not limited to) systemd. Requiring people to understand the current low level structure of their OS just to get some extra debug reporting on a failed boot is exposing implementation details.

Re: Response to systemd's use of the debug flag

#36
post #31
post #28

Earlier quoted context omitted.

Uhm without Linux specific kernel details systemd would not exist. This as well as journalctl taking minutes to show logs after months of normal usage...systemd is out from my Arch.

May I suggest OpenRC: http://blog.notfoss.com/posts/openrc-on-arch-linux/

Thanks, I am looking into openrc, as well as gnu dmd.
Post reply on HN