21–30 of 36 posts
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…
When I debug software, I do not want to lose logs and I do not want software to produce so much logs it is impossible to use.
>Correct. I don't mind people piggy-backing on some fairly obvious generic term like "debug" per se. I don't know if the old init scripts did that, but I do know they did it for "quiet", which is basically the reverse of "debug". >What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have b…
I have a fair amount of experience with Linux, but I'm a little lost by what's going on here. Can someone out there dumb this down a bit for an init newbie?
The kernel has a debug option that can be specified at boot time to increase its logging verbosity. systemd looks at the kernel command line to do the same and starts writing its own verbose logging out to the kernel's message buffer. Writing out to the kernel message buffer is done for pragmatic reasons: generally if you're debugging init problems they're happening when the machine is first starting so you would lik…
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.
Earlier quoted context omitted.
You can pass the kernel options before booting. i.e. "quiet" or "debug". The Kernel exposes these options via /proc/cmdline. systemd parses /proc/cmdline and if "debug" is set, it also raises it's log level to debug. Then systemd logs so much to the kernel log that it gets flooded and fails to boot. Edit: And story wise, systemd says yeah, we're not going to fix this or rename the debug flag for systemd to "systemd.d…
So basically, systemd is catching the common keyword 'debug' from a command that being given to something else entirely, and in turn enabling its own logging, which floods the system. The command wasn't actually meant for systemd, but for the kernel. Is that correct?
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, the bug is fixed in master branch".
The obvious answer to the second is "No, that's what it's for"
> A kernel is just one component of the OS among many, and ultimately an implementation detail. -- Lennard Poettering
This as well as journalctl taking minutes to show logs after months of normal usage...systemd is out from my Arch.
Earlier quoted context omitted.
The kernel has a debug option that can be specified at boot time to increase its logging verbosity. systemd looks at the kernel command line to do the same and starts writing its own verbose logging out to the kernel's message buffer. Writing out to the kernel message buffer is done for pragmatic reasons: generally if you're debugging init problems they're happening when the machine is first starting so you would lik…
> 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.
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…
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.