Bug#574073: kvm: No useful error message when hugepages are not available
On Thu, 18 Mar 2010, Michael Tokarev wrote: > I see 3 issues here: > > 1) bad error message _text_. It's fixed (only partially, -- I've looked > at the thing again and see more cases where it'll throw as useful > error messages as this one -- I'll add/send more patches for this). > At least this does not need to be discussed further, I think. Great! > 2) destination of error/warning messages. I disagree with your position >here, it is for this very reason we've separate stderr and stdout. If OK, there are other ways of getting the type of results I desire. > 3) -Werror mode. I somehow missed your second email in this bug#, where >you said: > > " > I think that this particular error should result in aborting the attempt > to run kvm. When I specifically instruct the program to do a particular > action and it's unable to do so that's a good cause for aborting with an > error. IMHO work-arounds should be implemented by humans not software. > " > >Valid points, and it's the same as with -enable-kvm and inability to >use /dev/kvm for some reason (#574063). > >And this is where the real question is, and what is this bug about, or >at least I will treat it this way. > > Does it sound right? Yes, that's fine. If you make it always do what I tell it to do then there would not be much need for error messages about failure modes. > But for 3), and #574063, I think the two bugs should be merged together. > There are other cases like this, and before trying to deal with the > issues, there should be general consensus about how to solve similar > problems. Sure. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
Russell Coker wrote: > On Tue, 16 Mar 2010, Michael Tokarev wrote: >>> Or kvm could use syslog or some other mechanism for logging such things. >> Where the error message will not be noticed either. With current >> form it at least has a chance to be noticed after the guest exits. > > There is no requirement that an error be logged in only one way. It's a > fairly common practice to use both stderr and syslog for logging the same > message. > >> In short, I disagree with your points, and think - based on my own >> experience - that currently kvm does the best (modulo the error message >> _text_). [] Rehashing it all. There are several points here, all inter-mixed. Let's sort them out one by one. I see 3 issues here: 1) bad error message _text_. It's fixed (only partially, -- I've looked at the thing again and see more cases where it'll throw as useful error messages as this one -- I'll add/send more patches for this). At least this does not need to be discussed further, I think. 2) destination of error/warning messages. I disagree with your position here, it is for this very reason we've separate stderr and stdout. If you expect to see some (large) output on stdout, and there may be some (usually small) messages on stderr, redirect stderr to a file. Think about, say, tar(1): `tar cfv foo.tar /home' -- it will show tons of filenames as it packs them, and you'll hardly notice the first "Warning: removing leading `/' from pathnames" or even wont know why it said "Exiting with non-zero status due to previous errors" because some file(s) disappeared while it worked. It is exactly the same with qemu behavior at hand. To me, this is not a problem or bug which needs fixing or discussing. 3) -Werror mode. I somehow missed your second email in this bug#, where you said: " I think that this particular error should result in aborting the attempt to run kvm. When I specifically instruct the program to do a particular action and it's unable to do so that's a good cause for aborting with an error. IMHO work-arounds should be implemented by humans not software. " Valid points, and it's the same as with -enable-kvm and inability to use /dev/kvm for some reason (#574063). And this is where the real question is, and what is this bug about, or at least I will treat it this way. Does it sound right? But for 3), and #574063, I think the two bugs should be merged together. There are other cases like this, and before trying to deal with the issues, there should be general consensus about how to solve similar problems. [] >> I'm relatively new to Debian still (speaking of package maintenance >> anyway) and don't know how a maintainer usually should treat ideas >> and suggestions about a package when said ideas are clearly should >> be at least discussed with upstream, -- the actual author(s) of the >> piece of software in question. > > There is some disagreement on this topic. I believe that a DD should forward > requests to upstream. I believe that there are two situations where the DD > should direct the reporter to contact upstream: > 1) The DD refuses to support a feature without upstream support and upstream > has indicated that they won't support it. > 2) The DD thinks it's just a bad idea and uses "please contact upstream" to > mean "please go away". This is what I think about 2) above -- "hiding" error messages with -curses. I'm not saying "go away", but I disagree that it's something that needs fixing -- it's _my_ opinion, not upstream's, but it so happens the two are quite similar... :) Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
On Tue, 16 Mar 2010, Michael Tokarev wrote: > > Or kvm could use syslog or some other mechanism for logging such things. > > Where the error message will not be noticed either. With current > form it at least has a chance to be noticed after the guest exits. There is no requirement that an error be logged in only one way. It's a fairly common practice to use both stderr and syslog for logging the same message. > In short, I disagree with your points, and think - based on my own > experience - that currently kvm does the best (modulo the error message > _text_). I fully agree about the usefulness of the particular error > message, and I already sent a patch to upstream fixing this (trivial > one-liner). Thanks. > For kvm we're talking about optional features, and how to react to them > lacking - either continue with a warning or stop - depends on the point > of view. A point of view which can be expressed by command-line options - similar to -Werror. > Ditto about error reporting in case of -curses. Note that the same > theme pops up in context of -daemon option, where kvm may actually > close stderr as you mentioned above. open /dev/kvm: Permission denied Could not initialize KVM, will disable KVM support Good point, when both /dev/kvm and /hugepages are unavailable with the -daemonize option only the above error is logged. > I'm relatively new to Debian still (speaking of package maintenance > anyway) and don't know how a maintainer usually should treat ideas > and suggestions about a package when said ideas are clearly should > be at least discussed with upstream, -- the actual author(s) of the > piece of software in question. There is some disagreement on this topic. I believe that a DD should forward requests to upstream. I believe that there are two situations where the DD should direct the reporter to contact upstream: 1) The DD refuses to support a feature without upstream support and upstream has indicated that they won't support it. 2) The DD thinks it's just a bad idea and uses "please contact upstream" to mean "please go away". With my packages I sometimes refer bugs upstream, and more often I fix the bugs and send the patch upstream. For me being a package maintainer is strongly correlated with being an upstream developer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
Russell Coker wrote: > On Tue, 16 Mar 2010, Michael Tokarev wrote: >>> When the path specified by -mem-path isn't writable the error message >>> "mkstemp: Permission denied" is displayed on stderr - which means that it >>> can't be seen until after the kvm session is ended when using the -curses >>> option. >> Russell, it's the same thing as #574063 again. If you redirected stderr >> to /dev/null, please don't complain that you see no useful error message. > > But when an application redirects it's own output to /dev/null it's something > that needs to be fixed - I've filed Debian bug reports about that before. In this case the application does not do any redirections, and the output is actually visible, but only after guest output gets erased. >> With -curses the current terminal is used for entirely different purpose >> (guest output), and if you at the same time want to see stderr, redirect >> it to a file or a pipe, or use some management software. > > Or kvm could use syslog or some other mechanism for logging such things. Where the error message will not be noticed either. With current form it at least has a chance to be noticed after the guest exits. In short, I disagree with your points, and think - based on my own experience - that currently kvm does the best (modulo the error message _text_). I fully agree about the usefulness of the particular error message, and I already sent a patch to upstream fixing this (trivial one-liner). >> Generally, and it applies to #574063 too, kvm lacks control over "failure >> reaction": here when it is unable to allocate hugepages, and in #574063, >> when it can't initialize /dev/kvm, and in some other cases, it currently >> continues, but sometimes it is useful to stop here with error. There is >> no way currently to tell kvm to turn such "warning" messages into fatal >> errors. > > The lack of a way to turn warnings into fatal errors is a bug. Think > of -Werror for C compilation. -Werror is something different really. For kvm we're talking about optional features, and how to react to them lacking - either continue with a warning or stop - depends on the point of view. Some will say current ways is good, others says it is not, and both has their points. For now it is upstream decision, and I think the best option - if you want the discussion about errors-vs-warnings to continue with some productivity - is to move it to upstream mailinglist. Ditto about error reporting in case of -curses. Note that the same theme pops up in context of -daemon option, where kvm may actually close stderr as you mentioned above. I'm relatively new to Debian still (speaking of package maintenance anyway) and don't know how a maintainer usually should treat ideas and suggestions about a package when said ideas are clearly should be at least discussed with upstream, -- the actual author(s) of the piece of software in question. But in any way, I personally do not see a problem here, from "error reporting" perspective (however, the -daemon case needs to be checked). About treating warnings as errors, -- this is actually useful, at least for #574063, -- so my current plan is to left both bugs open for now, and close #574063 when kvm will be able to stop if no kvm extensions are present and close this #574073 after changing text of the error message to something more meaningful. >> By the way, 0-72 version as shipped in Lenny is a joke nowadays. It is >> not a bad development snapshot, but it is still a development snapshot, >> just like all other kvm-NN "releases" were. If you intend to play or >> even use kvm, grab it from backports (it's called qemu-kvm there) - this >> version is a bit closer to released software than kvm-72 in lenny. I for >> one will not try to support it in any way, unless the same problem exists >> in qemu-kvm-0.12. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574060 > > My first attempt at reporting such bugs involved reproducing some of them on > Unstable, but unfortunately they got lost (see the above reportbug bug). Yeah, it's PITA when debuggers needs to be debugged before being useful... But I were talking about bpo really, not about unstable. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
On Tue, 16 Mar 2010, Michael Tokarev wrote: > > When the path specified by -mem-path isn't writable the error message > > "mkstemp: Permission denied" is displayed on stderr - which means that it > > can't be seen until after the kvm session is ended when using the -curses > > option. > > Russell, it's the same thing as #574063 again. If you redirected stderr > to /dev/null, please don't complain that you see no useful error message. But when an application redirects it's own output to /dev/null it's something that needs to be fixed - I've filed Debian bug reports about that before. > With -curses the current terminal is used for entirely different purpose > (guest output), and if you at the same time want to see stderr, redirect > it to a file or a pipe, or use some management software. Or kvm could use syslog or some other mechanism for logging such things. > Generally, and it applies to #574063 too, kvm lacks control over "failure > reaction": here when it is unable to allocate hugepages, and in #574063, > when it can't initialize /dev/kvm, and in some other cases, it currently > continues, but sometimes it is useful to stop here with error. There is > no way currently to tell kvm to turn such "warning" messages into fatal > errors. The lack of a way to turn warnings into fatal errors is a bug. Think of -Werror for C compilation. > By the way, 0-72 version as shipped in Lenny is a joke nowadays. It is > not a bad development snapshot, but it is still a development snapshot, > just like all other kvm-NN "releases" were. If you intend to play or > even use kvm, grab it from backports (it's called qemu-kvm there) - this > version is a bit closer to released software than kvm-72 in lenny. I for > one will not try to support it in any way, unless the same problem exists > in qemu-kvm-0.12. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574060 My first attempt at reporting such bugs involved reproducing some of them on Unstable, but unfortunately they got lost (see the above reportbug bug). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
Russell Coker wrote: > Package: kvm > Version: 72+dfsg-5~lenny5 > Severity: normal > > When the path specified by -mem-path isn't writable the error message > "mkstemp: Permission denied" is displayed on stderr - which means that it > can't be seen until after the kvm session is ended when using the -curses > option. Russell, it's the same thing as #574063 again. If you redirected stderr to /dev/null, please don't complain that you see no useful error message. With -curses the current terminal is used for entirely different purpose (guest output), and if you at the same time want to see stderr, redirect it to a file or a pipe, or use some management software. Generally, and it applies to #574063 too, kvm lacks control over "failure reaction": here when it is unable to allocate hugepages, and in #574063, when it can't initialize /dev/kvm, and in some other cases, it currently continues, but sometimes it is useful to stop here with error. There is no way currently to tell kvm to turn such "warning" messages into fatal errors. > Also the error message doesn't have an obvious meaning. Yes, this is a valid point, and I think I'll get it fixed. I'll close this bug if you don't have further points. By the way, 0-72 version as shipped in Lenny is a joke nowadays. It is not a bad development snapshot, but it is still a development snapshot, just like all other kvm-NN "releases" were. If you intend to play or even use kvm, grab it from backports (it's called qemu-kvm there) - this version is a bit closer to released software than kvm-72 in lenny. I for one will not try to support it in any way, unless the same problem exists in qemu-kvm-0.12. And thank you for bringing this option under my attention - I overlooked it somehow until you pointed me it. Very good thing! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574073: kvm: No useful error message when hugepages are not available
Package: kvm Version: 72+dfsg-5~lenny5 Severity: normal When the path specified by -mem-path isn't writable the error message "mkstemp: Permission denied" is displayed on stderr - which means that it can't be seen until after the kvm session is ended when using the -curses option. Also the error message doesn't have an obvious meaning. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
