Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 12:27 AM, Greg KH gre...@linuxfoundation.org wrote:
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).
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.
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
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
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
Hi On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
Am 03.04.2014 11:36, schrieb David Herrmann: On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: 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. Let me quote Linus from http://www.spinics.net/lists/kernel/msg1716484.html: 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.) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 00:27, Greg KH wrote: 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. 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did gyre and gimble: On 03.04.2014 00:27, Greg KH wrote: 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. 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. 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On 03.04.2014 15:48, Colin Guthrie wrote: 'Twas brillig, and Florian Albrechtskirchinger at 03/04/14 11:53 did gyre and gimble: 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. Of course. I figured, I would start with the presumably easier side first ;) 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. 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… 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. 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. 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger falbrechtskirchin...@gmail.com wrote: 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. -1 on this because it moves in the opposite direction of namespace clarity. systemd should not use both more verbose, namespaced versions of kernel options and abbreviated, non-namespaced versions of the same. At least do sd.dbg or similar; we already use sd as a namespace prefix elsewhere. With respect to the main change suggested in this thread, I'm a +1 for systemd.debug, especially because it's consistent with log level options. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
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/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
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Wed, Apr 02, 2014 at 03:27:52PM -0700, Greg KH wrote:
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/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) {
I think kernel-command-line(7) will need an update to go with this.
/* Log to kmsg, the journal socket will fill up before the
* journal is started and tools running during that time
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
