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

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote:
> On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > 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.
> 
> Btw, I don't think what makes the most sense to "us" (systemd devs) is
> really that important, nor what makes sense to kernel devs. All of us
> are more than capable of passing whatever combination of commandline
> options necessary to get the effect we want. What we should care about
> is people who don't spend all their time debugging kernel/init. I.e.,
> end-users, support channels, etc. As long as people are not even
> arguing from that point of view, I don't think we will get anywhere
> with this...
Well, the example with F20 boot bugs I cite was exactly about that.

> > Having 'debug' as one-stop option for
> > less experienced users was totally appropriate.

Zbyszek