[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd

Hash: SHA512

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.

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

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...

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: