Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 9:26 PM, David Timothy Strauss wrote: > On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John wrote: >> "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." 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. That's a good point. Would patches be accepted that allowed both "systemd.log_level" and "init.log_level", etc.? Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John wrote: > "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." 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 4:16 PM, 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 >> > >> > 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"? > >> 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 "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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 11:44 PM, Zbigniew Jędrzejewski-Szmek wrote: > 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 >> 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 >> >> > > >> >> > > 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mail
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
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 > 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 > >> > > > >> > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
Am 05.04.2014 23:22, schrieb 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. 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 v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek 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 >> > > >> > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
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 > > > > > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
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 > > > > 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"? > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > From: 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Thu, Apr 03, 2014 at 08:18:26AM -0700, Greg KH wrote: > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > > From: 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. > > > > Signed-off-by: Greg KH > > Again, I never added this line :( That being said, your modification of my original patch looks correct, thanks for doing that. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > From: 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. > > Signed-off-by: Greg KH Again, I never added this line :( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
From: 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.
Signed-off-by: Greg KH
Signed-off-by: Hannes Reinecke
---
man/kernel-command-line.xml | 4 ++--
src/core/main.c | 21 +++--
2 files changed, 13 insertions(+), 12 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 @@
-debug
+systemd.debug
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..2ca038c 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."))) {
@@ -408,7 +417,8 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
"systemd.default_standard_error=null|tty|syslog|syslog+console|kmsg|kmsg+console|journal|journal+console\n"
" Set
default log error output for services\n"
"systemd.setenv=ASSIGNMENTSet
an environment variable for all spawned processes\n"
- "systemd.restore_state=0|1
Restore backlight/rfkill state at boot\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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
