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

[Tom Gundersen]

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

-t