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 da...@davidstrauss.net wrote: On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu 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.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. 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 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 gre...@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? 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 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 gre...@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. 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 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek zbys...@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 gre...@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 ___ 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 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote: On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek zbys...@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 gre...@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 ___ 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 zbys...@in.waw.pl 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 zbys...@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 gre...@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. 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/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 gre...@linuxfoundation.org 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 gre...@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? 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 4:06 PM, Jason St. John jstj...@purdue.edu 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.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. ___ 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 gre...@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. 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 04:08:15PM +0200, Hannes Reinecke wrote: From: Greg KH gre...@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 gre...@linuxfoundation.org Again, I never added this line :( ___ 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 gre...@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 gre...@linuxfoundation.org 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