Re: I'm not a huge fan of systemd
On Tue, Jul 22, 2014 at 11:01 AM, The Wanderer <wanderer@fastmail.fm> wrote:
> On 07/22/2014 10:34 AM, Tom H wrote:
>> On Mon, Jul 21, 2014 at 12:47 PM, Erwan David <erwan@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.
Reply to: