[systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote:
> On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
> > > From: Greg KH <gregkh at linuxfoundation.org>
> > > 
> > > If the kernel is started with "debug", that's for the kernel to switch
> > > into debug mode.  We should rely on a namespace for our options, like
> > > everything else (with the exception of "quiet").  Some people want to
> > > only debug the kernel, not systemd, and the opposite as well so make
> > > everyone happy.
> > Essentialy, this patch adds systemd.debug as an alias for
> > systemd.log_level=debug systemd.log_target=console. But it doesn't
> > really fix anything, just moves the initial problem to a different set
> > of options.
> 
> What needs to be "fixed"?
The fact that kernel in debug + systemd in debug mode mode produced
enough data to case a failed boot. I didn't follow the details of what
exactly broke, but at least systemd is (was?) logging a stupid
assertion.

> > This isn't useful. In addition, it is reasonable to use "debug" to
> > turn on verbose mode for the kernel + init combo, since in practice
> > this is what people need to diagnose boot problems.
> 
> Well, the intersection of people that have a problem with both the
> kernel and systemd at boot time are probably quite small.  As a kernel
> developer, I tell people to turn on debug all the time to find issues in
> different drivers and the like.  They aren't having any problems with
> systemd, so any extra messages that it causes, isn't going to be
> helpful.
It's a tradeoff, and there are cases where one meaning or the other
would be more convenient. We can certainly find lots or examples and
counterexamples... E.g. for me the recent slew of issues with boot
getting stuck in F20, which seemed to have been caused by a
combination of kernel, systemd, plymouth, and gdm or kdm issues, was
quite important and visible. Having 'debug' as one-stop option for
less experienced users was totally appropriate.

In fact, this setting has been interpreted this way by systemd for a
while now, and this bug report is the first complaint about that that
I'm aware of.

The whole issue started with bug #76935: the original reporter was
seemingly unaware of available kernel commandline options, and his
comments fairly quickly degenerated to rude personal attacks. It's
something that one sees quite often: a complaint, a reply how
requested goals can be achieved and why things are implemented the way
they are, followed by demands of having it "my way", followed by a fit
and swearing. Then come "Anonymous Helpers". I really don't see why we
should deal with this shit and waste time on people who evidently want
to vent their frustration rather than solve a bug.

> Probably the same thing happens for people who are having problems with
> systemd.
> 
> So I thought it would make more sense to have separate options, as the
> two things really are two different projects / code bases.  Having the
> same flag makes it easy for a small subset of people who would be doing
> work in both areas, and even then, having to add a simple
> "systemd.debug" flag to the command line for that doesn't seem to be a
> big deal.
We already have systemd.log_level=debug which is well known... And
usually systemd debugging is most useful together with kernel debugging,
so the shared interpretation makes the most sense for us.

Zbyszek