On Tue, Jul 22, 2014 at 11:01 AM, The Wanderer <wande...@fastmail.fm> wrote: > On 07/22/2014 10:34 AM, Tom H wrote: >> On Mon, Jul 21, 2014 at 12:47 PM, Erwan David <er...@rail.eu.org> >> wrote: >>> >>> So it seems there is a quiet on the default command line, which >>> does not mean same thing when using systemd or using init. >>> >>> I do not want full verbose, I would like previous behaviour. Where >>> I could see in one glance whether it was working or blocked without >>> having too many messages. >> >> I remember someone's post advising you to use >> "systemd.show_status=true" on the kernel cmdline. >> >> But this is from the systemd man page >> >> == %< ======== >> systemd.show_status= >> Takes a boolean argument or the constant auto. If true, shows terse >> service status updates on the console during bootup. auto behaves >> like false until a service fails or there is a significant delay in >> boot. Defaults to true, unless quiet is passed as kernel command line >> option in which case it defaults to auto. >> >> quiet >> Turn off status output at boot, much like systemd.show_status=false >> would. Note that this option is also read by the kernel itself and >> disables kernel log output. Passing this option hence turns off the >> usual output from both the system manager and the kernel. >> == >% ======== >> >> so you shouldn't have need it.
It should've been "so you shouldn't have needed it"... > If memory serves, this (systemd doing things differently in response to > the presence of non-namespaced, generic arguments on the kernel command > line) is exactly what triggered the famous "Linus blacklists Kay Sievers > from getting code upstream" incident. > > Specifically, in that case, systemd was reading 'debug' from the kernel > command line and outputting such floods of information that the boot > process was extremely slow and debugging it was actually hampered. > > The use of 'quiet' by systemd doesn't cause quite the same type of > issue, but it does still mean that you can't silence kernel boot output > without also silencing systemd (init-system, and probably consequently > "service") boot output, which means it's another class of the same > problem. > > The "right" solution here would be for systemd to stop consuming, or > otherwise reacting to, any non-namespaced kernel-command-line arguments. > ("Namespaced" here means e.g. with the "systemd." prefix, as with > 'systemd.show_status' above. Responding to 'systemd.quiet' or > 'systemd.debug' would be just fine.) I actually thought this had already > been done, in response to the 'debug' incident, but maybe not - or maybe > even they only did it for 'debug' itself, not more generally... Linus has said that parsing "quiet" and "debug" is OK. The "debug" problem's been fixed; IIRC it was fixed before the lkml lovefest. AIUI, the kernel's rate-limiting logging to "/dev/kmsg" and systemd stops logging to "/dev/kmsg" once journald is up and running. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=sz8p-xro+zona020+gswpmpjxpt5py4+hws_5zoal5...@mail.gmail.com