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

Dave Reisner

2014-04-02 23:43:14 UTC

I think kernel-command-line(7) will need an update to go with this.

Post by Greg KH
/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Greg KH

2014-04-02 23:52:27 UTC

Post by Dave Reisner

I think kernel-command-line(7) will need an update to go with this.

Oops, missed that, I'll fix that up after dinner, thanks.

greg k-h

Greg KH

2014-04-03 01:02:32 UTC

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.

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec612891a..19da7a3431b0 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
</varlistentry>

<varlistentry>
- <term><varname>debug</varname></term>
+ <term><varname>systemd.debug</varname></term>
<listitem>
<para>Parameter understood by
- both the kernel and the system
+ the system
and service manager to control
console log verbosity. For
details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee8d5cd..291b18519388 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -416,7 +416,7 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;

- } else if (streq(key, "debug") && !value) {
+ } else if (streq(key, "systemd.debug") && !value) {

/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time

Hannes Reinecke

2014-04-03 06:45:36 UTC

Post by Greg KH
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.
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec612891a..19da7a3431b0 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
</varlistentry>
<varlistentry>
- <term><varname>debug</varname></term>
+ <term><varname>systemd.debug</varname></term>
<listitem>
<para>Parameter understood by
- both the kernel and the system
+ the system
and service manager to control
console log verbosity. For
details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee8d5cd..291b18519388 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -416,7 +416,7 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;
- } else if (streq(key, "debug") && !value) {
+ } else if (streq(key, "systemd.debug") && !value) {
/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time

... only that it doesn't work as it'll be filtered out by the

} else if (startswith(word, "systemd.") ||

clause just before that.

Cheers,

Hannes

--
Dr. Hannes Reinecke zSeries & Storage
***@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Colin Guthrie

2014-04-03 10:44:21 UTC

Post by Greg KH
+ } else if (streq(key, "systemd.debug") && !value) {

Just as a small not to user typos, perhaps we should also check for
"system.debug"? It's a bit of a namespace crime, but it might avoid some
unneeded round trips requesting logs from users.

While it's now practically impossible for me to type the word "system"
_without_ putting a "d" on the end, many people triaging boot bugs at a
distro level will be advising users to edit their command prompt and
append "debug systemd.debug" and send in their logs which could easily
be misread by novice users, especially if they are totally unaware of
what systemd is (they may never even have heard the name before) - not
everyone who needs to collect debug information is a developer after all.

Just a small thought.

Cheers

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/

Hannes Reinecke

2014-04-03 06:52:06 UTC

From: Greg KH <***@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.

Signed-off-by: Greg KH <***@linuxfoundation.org>
Signed-off-by: Hannes Reinecke <***@suse.de>
---
man/kernel-command-line.xml | 4 ++--
src/core/main.c | 19 ++++++++++---------
2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec61..19da7a3 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
</varlistentry>

<varlistentry>
- <term><varname>debug</varname></term>
+ <term><varname>systemd.debug</varname></term>
<listitem>
<para>Parameter understood by
- both the kernel and the system
+ the system
and service manager to control
console log verbosity. For
details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee..bbacfd1 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -374,6 +374,15 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
} else
log_warning("Environment variable name '%s' is not valid. Ignoring.", value);

+ } else if (streq(key, "systemd.debug") && !value) {
+
+ /* Log to kmsg, the journal socket will fill up before the
+ * journal is started and tools running during that time
+ * will block with every log message for for 60 seconds,
+ * before they give up. */
+ log_set_max_level(LOG_DEBUG);
+ log_set_target(detect_container(NULL) > 0 ? LOG_TARGET_CONSOLE : LOG_TARGET_KMSG);
+
} else if (!streq(key, "systemd.restore_state") &&
!streq(key, "systemd.gpt_auto") &&
(startswith(key, "systemd.") || startswith(key, "rd.systemd."))) {
@@ -409,6 +418,7 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
" Set default log error output for services\n"
"systemd.setenv=ASSIGNMENT Set an environment variable for all spawned processes\n"
"systemd.restore_state=0|1 Restore backlight/rfkill state at boot\n");
+ "systemd.debug Enable debugging output\n");
}

} else if (streq(key, "quiet") && !value) {
@@ -416,15 +426,6 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;

- } else if (streq(key, "debug") && !value) {
-
- /* Log to kmsg, the journal socket will fill up before the
- * journal is started and tools running during that time
- * will block with every log message for for 60 seconds,
- * before they give up. */
- log_set_max_level(LOG_DEBUG);
- log_set_target(detect_container(NULL) > 0 ? LOG_TARGET_CONSOLE : LOG_TARGET_KMSG);
-
} else if (!in_initrd() && !value) {
unsigned i;

--
1.8.1.4

Colin Guthrie

2014-04-03 11:02:24 UTC

Post by Hannes Reinecke
"systemd.restore_state=0|1 Restore backlight/rfkill state at boot\n");
+ "systemd.debug Enable debugging output\n");

Line above the change line should have the ); removed...

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/

Hannes Reinecke

2014-04-03 14:00:37 UTC

Post by Colin Guthrie

Post by Hannes Reinecke
"systemd.restore_state=0|1 Restore backlight/rfkill state at boot\n");
+ "systemd.debug Enable debugging output\n");

Line above the change line should have the ); removed...

Indeed. Serves me right for not having tested them.

Sorry for this.

Cheers,

Hannes

--
Dr. Hannes Reinecke zSeries & Storage
***@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Greg KH

2014-04-03 15:17:29 UTC

NEVER add this line to a patch from someone who did not add it
themselves, as it means something.

Come on, you know better Hannes...

greg k-h

Hannes Reinecke

2014-04-04 05:51:03 UTC

NEVER add this line to a patch from someone who did not add it
themselves, as it means something.
Come on, you know better Hannes...

Sorry.
Won't happen again.

Cheers,

Hannes

--
Dr. Hannes Reinecke zSeries & Storage
***@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Zbigniew Jędrzejewski-Szmek

2014-04-05 05:11:47 UTC

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

Zbyszek

Greg KH

2014-04-05 20:16:12 UTC

What needs to be "fixed"?

Post by Zbigniew JÄdrzejewski-Szmek
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.

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.

thanks,

greg k-h

Zbigniew Jędrzejewski-Szmek

2014-04-05 21:22:06 UTC

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.

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.

Post by Greg KH
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

Tom Gundersen

2014-04-05 21:32:50 UTC

On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek

What needs to be "fixed"?

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.

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

Zbigniew Jędrzejewski-Szmek

2014-04-05 21:44:49 UTC

Post by Tom Gundersen
On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek

What needs to be "fixed"?

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.

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.

Well, the example with F20 boot bugs I cite was exactly about that.

Post by Tom Gundersen

Post by Zbigniew JÄdrzejewski-Szmek
Having 'debug' as one-stop option for
less experienced users was totally appropriate.

Zbyszek

Tom Gundersen

2014-04-05 21:58:04 UTC

On Sat, Apr 5, 2014 at 11:44 PM, Zbigniew Jędrzejewski-Szmek

Post by Tom Gundersen
On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek

What needs to be "fixed"?

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.

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.

Well, the example with F20 boot bugs I cite was exactly about that.

Yes, indeed you did cover that. Bad phrasing from my side. What I
meant is that the counter argument (i.e., the argument why we should
change the current behavior) is not being made in terms of what is the
most useful to the majority of our user-base, merely what is the most
useful to kernel developers...

-t

Reindl Harald

2014-04-05 21:37:54 UTC

Post by Zbigniew JÄdrzejewski-Szmek
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.

cause and effect, the rude attacks maybe because ignorance
and frustration about the "we are always right" attitude

what makes sense *to you* is not the only relevant thing!

http://lkml.org/lkml/2012/10/3/484
http://www.spinics.net/lists/kernel/msg1716484.html
https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF

i guess Kay will now remove me from that list because as affected user i have
to shut up in general but that does not change anything in casue and effect
and that there are enough people with zero understanding for ""I really don't
see why we should deal with this shit" which is your userbase - if you are
not interested in users you should make a private project but not the first
most imporant piece after the kernel because that brings *responsibility*
___________________________________________________

no other software than systemd logs that much to *bury*
any for a non-systemd-developer relevant infos even under
normal operations

http://www.spinics.net/lists/kernel/msg1716484.html
Linus words "I personally find it annoying that it's always
the same f*cking primadonna involved" are hardly because
*that one* thing and should lead to consider things are
handeled wrong instead continue with "I really don't see why we
should deal with this shit"

the following parapgraph talks also about a general attitude
that anybody with critism is treated as enemy all the time
and everything left and right of systemd is broken in general
and has to be fixed because it stands in the way of systemd

It does become a problem when you have a system service developer who
thinks the universe revolves around him, and nobody else matters, and
people sending him bug-reports are annoyances that should be ignored
rather than acknowledged and fixed. At that point, it's a problem.

Jason St. John

2014-04-05 23:06:23 UTC

What needs to be "fixed"?

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.
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.
thanks,
greg k-h

"init.debug" would be better than "systemd.debug", in my opinion. It
is shorter (less typing and no possible end-user confusion over
"systemd.debug" vs. "system.debug"), and it is init-agnostic. Other
init systems (OpenRC, Upstart, etc.) would be able to add their own
support for this, if they want, without requiring an init-specific
kernel parameter.

It just seems a lot simpler this way.

Jason

David Timothy Strauss

2014-04-06 01:26:39 UTC

Post by Jason St. John
"init.debug" would be better than "systemd.debug", in my opinion. It
is shorter (less typing and no possible end-user confusion over
"systemd.debug" vs. "system.debug"), and it is init-agnostic. Other
init systems (OpenRC, Upstart, etc.) would be able to add their own
support for this, if they want, without requiring an init-specific
kernel parameter.
It just seems a lot simpler this way.

It would be a little odd given how "systemd.<name>" is how other
probably portable options get namespaced. Arguably, systemd.log_level
would become init.log_level. I'm not against it, but it couldn't be
just init.debug.

Jason St. John

2014-04-09 00:43:49 UTC

Post by David Timothy Strauss

On Sat, Apr 5, 2014 at 9:26 PM, David Timothy Strauss

That's a good point. Would patches be accepted that allowed both
"systemd.log_level" and "init.log_level", etc.?

Jason

Tom Gundersen

2014-04-03 09:08:52 UTC

Just a quick note, we do in fact read a lot of kernel parameters in
addition to 'debug' and 'quiet'. What springs to mind is 'init=',
'root=', 'rootflags=', 'rootfs=', 'ro', 'rw', and 'ip=' (there are
probably more, but these are the ones I added myself). My
understanding was that reusing the kernel commandline options, in a
consistent way, is generally ok. But I may of course have gotten the
wrong end of the stick here.

Post by Greg KH
Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.

I asked this before, but I guess this is the correct forum, so I'll
repeat myself:

My understanding is that currently we have "systemd.log_level=" which
affects only systemd, and "loglevel=" which affects only the kernel.
Moreover, "debug" currently implies "systemd.log_level=debug
loglevel=debug" (and as far as I know it will also increase the debug
output of other system-level processes, but these don't log much and
anyway not via the kernel, so let's ignore those).

This proposal is about making "debug" equivalent to "loglevel=debug"
and hence not affect systemd at all.

Is the rationale for this, simply a matter of preference, i.e., is the
claim simply that we believe most users would benefit more from the
'kernel only' compared to 'all low-level stuff' behavior? If that's
the case, I don't have an opinion on the patch, so I'll leave it to
those who do :)

Or is there actually a bug going on here? My impression from reading
related discussions was that "systemd.log_level=debug loglevel=debug"
triggers some bug (so in particular "debug" now triggers the bug). It
was not clear to me whether boot itself hangs, or if log-in becomes
impossible. Either way, I'm not able to reproduce it, so if anyone has
any more info on this, that would be useful.

Cheers,

Tom

Post by Greg KH
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee8d5cd..291b18519388 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -416,7 +416,7 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
if (arg_show_status == _SHOW_STATUS_UNSET)
arg_show_status = SHOW_STATUS_AUTO;
- } else if (streq(key, "debug") && !value) {
+ } else if (streq(key, "systemd.debug") && !value) {
/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Tom Gundersen

2014-04-03 09:15:57 UTC

Post by Tom Gundersen
Is the rationale for this, simply a matter of preference, i.e., is the
claim simply that we believe most users would benefit more from the
'kernel only' compared to 'all low-level stuff' behavior? If that's
the case, I don't have an opinion on the patch, so I'll leave it to
those who do :)

Ok, I may care a bit, so I'll add my two cents:

I suppose the general use-case here (i.e., not seen from the point of
view of either a kernel or a systemd developer, but trying to imagine
an end-user), is when 'boot is broken'. In that case, it makes a lot
of sense to me to have a simple switch to give all the relevant debug
info about the boot process. There are basically two things that may
be broken: the kernel or systemd (or the initrd if that's !=systemd),
and the end-user probably doesn't care much for the distinction. I'd
therefore think it makes the most sense for "debug" to trigger
debugging of all these things. I'm sure there are ways to see this to
justify the opposite view though...

Cheers,

Tom

David Herrmann

2014-04-03 09:36:57 UTC

Post by Tom Gundersen
Or is there actually a bug going on here? My impression from reading
related discussions was that "systemd.log_level=debug loglevel=debug"
triggers some bug (so in particular "debug" now triggers the bug). It
was not clear to me whether boot itself hangs, or if log-in becomes
impossible. Either way, I'm not able to reproduce it, so if anyone has
any more info on this, that would be useful.

There was a bug there which triggered the assertions. However, it has
been fixed in -git for quite some time, so with -git systemd will
_not_ log an unreasonable amount of information.

Thanks
David

Thomas Bächler

2014-04-03 10:52:47 UTC

Post by David Herrmann

There was a bug there which triggered the assertions. However, it has
been fixed in -git for quite some time, so with -git systemd will
_not_ log an unreasonable amount of information.
No, we very much expose /proc/cmdline for a reason. System services
are *supposed* to parse it, because it gives a unified way for people
to pass in various flags.
[...]
And yes, that does include "quiet" and "debug". Parsing them and doing
something sane with them is not a bug, it's a feature.

The original complaint was that the systemd debug output was so
excessive that the system became unusable and the debug output
unreadable. If what Hermann said above is true and that problem has been
fixed, then the debug output is "sane" now and everything is fine. In
that case, there is nothing to do. (In fact, the problem was already
identified and fixed before this whole discussion started.)

Is there anything else I am missing here?

(Adding Linus and Greg to CC to see if there actually is something that
I am missing.)

Florian Albrechtskirchinger

2014-04-03 10:53:27 UTC

Allow me to propose an alternative to 'debug' and 'systemd.debug'.

When I debug boot issues and add 'debug' to the kernel command line, I
do it by editing the command line through the boot loader and I might
do it several times in a row, so I want the option to be short. I
imagine that's a common workflow and is one of the reasons everybody
wants to claim 'debug'.

I suggest we return the 'debug' option to the kernel folk and add a new
option 'dbg' with a string of single letter arguments. For example,
'dbg=ki' (k for kernel, i for init) would activate debugging in the
kernel and the init system.
Further, r could be added for initrd debugging and 'dbg' on it's own
could default to 'dbg=kri'.

The new option would be short, flexible, and extensible, 'debug' could
still be used by kernel developers as they are used to, and it's
trivial to implement.

Wouldn't that make everyone happy?

Colin Guthrie

2014-04-03 13:48:20 UTC

Post by Florian Albrechtskirchinger

'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did

Allow me to propose an alternative to 'debug' and 'systemd.debug'.
When I debug boot issues and add 'debug' to the kernel command line, I
do it by editing the command line through the boot loader and I might
do it several times in a row, so I want the option to be short. I
imagine that's a common workflow and is one of the reasons everybody
wants to claim 'debug'.
I suggest we return the 'debug' option to the kernel folk and add a new
option 'dbg' with a string of single letter arguments. For example,
'dbg=ki' (k for kernel, i for init) would activate debugging in the
kernel and the init system.
Further, r could be added for initrd debugging and 'dbg' on it's own
could default to 'dbg=kri'.

I think this is a reasonable suggestion inline with the spirit of
finding a compromise.

You would first have to get agreement in principle from both sides that
merging patches to support this would be OK.

I would suggest that instead of an argument you make dbg a general
purpose debug namesapce prefix. So, dbg.k or dbg.kernel works on the
kernel side, and dbg.i or dbg.init works on the systemd side with dbg.r
and dbg.rd works on the the dracut side.

Post by Florian Albrechtskirchinger
Wouldn't that make everyone happy?

I doubt it. People would still disagree on what colour to make the
argument text ;)

Overall in this issue, I think one has to have a bit of pragmatism.
I agree in principle that "debug" should be a generic term, but really
there are bigger fights to fight and wasting energy on this battle
really seems counter productive to the bigger picture.

I think in this case, there is a little prior art to using "debug" on
the kernel where dracut used a namespaced version rd.debug for it's
debugging, so following that pattern systemd.debug seems logical enough.

I know it would be nice to have one argument to turn all debugging on,
but ultimately I feel there are bigger fish to fry than points of
principle here.

As far as I understand it none of the future plans really revolve around
this, so I say just change it and move on with making things awesome and
don't waste time on this point of principle.

We can still know we're right without actually implementing it :p

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/

Florian Albrechtskirchinger

2014-04-03 19:03:01 UTC

Post by Colin Guthrie
'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did

Post by Florian Albrechtskirchinger
I suggest we return the 'debug' option to the kernel folk and add a new
option 'dbg' with a string of single letter arguments. For example,
'dbg=ki' (k for kernel, i for init) would activate debugging in the
kernel and the init system.
Further, r could be added for initrd debugging and 'dbg' on it's own
could default to 'dbg=kri'.

Of course. I figured, I would start with the presumably easier side
first ;)

Post by Colin Guthrie
I would suggest that instead of an argument you make dbg a general
purpose debug namesapce prefix. So, dbg.k or dbg.kernel works on the
kernel side, and dbg.i or dbg.init works on the systemd side with dbg.r
and dbg.rd works on the the dracut side.

Style-wise I tend to agree, but I was going for brevity first and
foremost.

Post by Colin Guthrie

Post by Florian Albrechtskirchinger
Wouldn't that make everyone happy?

I doubt it. People would still disagree on what colour to make the
argument text ;)

"Everyone" is a big crowd, should have said "more people", then maybe…

Post by Colin Guthrie
Overall in this issue, I think one has to have a bit of pragmatism.
I agree in principle that "debug" should be a generic term, but really
there are bigger fights to fight and wasting energy on this battle
really seems counter productive to the bigger picture.

Agreed. I'm only mildly interested because of the fresh memory of
typing 'debug rd.debug ...' repeatedly over a day. Would have been nice
to have - not worth fighting anyone, though.

Post by Colin Guthrie
I think in this case, there is a little prior art to using "debug" on
the kernel where dracut used a namespaced version rd.debug for it's
debugging, so following that pattern systemd.debug seems logical enough.

It's definitely logical, but that's not my point at all.

Post by Colin Guthrie
I know it would be nice to have one argument to turn all debugging on,
but ultimately I feel there are bigger fish to fry than points of
principle here.

Both you and Tom Gundersen raised the point of assisting end-users with
boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as
concise and simple as it gets.

Post by Colin Guthrie
As far as I understand it none of the future plans really revolve around
this, so I say just change it and move on with making things awesome and
don't waste time on this point of principle.

I'm not going to push it, but if anyone (important) wants me to, I'm
still willing to bring it up on LKML and write patches.

Otherwise I'll move on. Good day.

Florian

David Timothy Strauss

2014-04-03 20:01:54 UTC