> 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.
Response to systemd's use of the debug flag
31–36 of 36 posts
Re: Response to systemd's use of the debug flag
#32With 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
#33Earlier 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.
Re: Response to systemd's use of the debug flag
#34I 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,…
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
#35Hmm, 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.
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
#36Earlier 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/