* [linux-lvm] lvcreate and lvremove --quiet option is not quiet @ 2011-02-14 15:46 Jeff 2011-02-14 16:31 ` Ray Morris 0 siblings, 1 reply; 8+ messages in thread From: Jeff @ 2011-02-14 15:46 UTC (permalink / raw) To: linux-lvm Background: I am using lvm snapshots in a backup script. My general scripting philosophy is that automation scripts that do not have errors should not generate output that will cause cron to send an email. I am using Ubuntu 10.04 with lvm2.02.54-1ubuntu4. Even with the --quiet option I get "Logical volume <name> created" on stdout with lvcreate and "Logical volume <name> successfully removed" with lvremove. So... I grabbed the source code and started nosing around. In lv_manip.c, I find that these messages are produced with a call to the function log_print. log_print is a macro (in log.h) for LOG_LINE(_LOG_WARN, args). So it looks like the logging system sees these messages as warnings and is printing them even though verbosity is turned down as far as possible. In addition to --quiet on the command line, I have verbose = 0 in lvm.conf which according to the man page "should produce no output". From my point of view, lv_manip.c should be calling the log_info macro for these messages and not log_print, thus giving the user control over the output as advertised by the documentation. Disclaimer: I did not dig into the source code far enough to be assured that log_info will generated the proper results, but it certainly appears on the surface to be the right option. I also downloaded the latest source tarball (2.0.2.84) and the situation appears to be the same. Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-14 15:46 [linux-lvm] lvcreate and lvremove --quiet option is not quiet Jeff @ 2011-02-14 16:31 ` Ray Morris 2011-02-14 17:43 ` Jeff 0 siblings, 1 reply; 8+ messages in thread From: Ray Morris @ 2011-02-14 16:31 UTC (permalink / raw) To: LVM general discussion and development; +Cc: jlar310 > My general scripting philosophy is that automation scripts that > do not have errors should not generate output that will cause cron > to send an email. > So... I grabbed the source code and started nosing around. So we'll look forward to seeing your patches I hope? It does seem logical that it shouldn't produce informational messages on stdout with --quiet. As to the first part, that got me thinking about the general rule. Is it generally agreed that commands which do not have errors "should not generate output" or that commands which do not have ERRORs "should not generate output on standard ERROR? The OP said that these messages are on stdout, not stderr. I'm kind of thinking that's right. No errors, nothing on standard error. If using --quiet, then no standard output. If lacking a quiet option, then cron jobs should redirect stdout to /dev/null, sending mail if there are errors on stderr. Thoughts? -- Ray Morris support@bettercgi.com Strongbox - The next generation in site security: http://www.bettercgi.com/strongbox/ Throttlebox - Intelligent Bandwidth Control http://www.bettercgi.com/throttlebox/ Strongbox / Throttlebox affiliate program: http://www.bettercgi.com/affiliates/user/register.php On Mon, 14 Feb 2011 09:46:05 -0600 Jeff <jlar310@gmail.com> wrote: > Background: I am using lvm snapshots in a backup script. My general > scripting philosophy is that automation scripts that do not have > errors should not generate output that will cause cron to send an > email. > > I am using Ubuntu 10.04 with lvm2.02.54-1ubuntu4. > > Even with the --quiet option I get "Logical volume <name> created" on > stdout with lvcreate and "Logical volume <name> successfully removed" > with lvremove. > > So... I grabbed the source code and started nosing around. In > lv_manip.c, I find that these messages are produced with a call to the > function log_print. log_print is a macro (in log.h) for > LOG_LINE(_LOG_WARN, args). So it looks like the logging system sees > these messages as warnings and is printing them even though verbosity > is turned down as far as possible. In addition to --quiet on the > command line, I have verbose = 0 in lvm.conf which according to the > man page "should produce no output". > > >From my point of view, lv_manip.c should be calling the log_info > >macro > for these messages and not log_print, thus giving the user control > over the output as advertised by the documentation. Disclaimer: I did > not dig into the source code far enough to be assured that log_info > will generated the proper results, but it certainly appears on the > surface to be the right option. > > I also downloaded the latest source tarball (2.0.2.84) and the > situation appears to be the same. > > Jeff > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-14 16:31 ` Ray Morris @ 2011-02-14 17:43 ` Jeff 2011-02-14 18:14 ` Alasdair G Kergon 0 siblings, 1 reply; 8+ messages in thread From: Jeff @ 2011-02-14 17:43 UTC (permalink / raw) To: linux-lvm On Mon, Feb 14, 2011 at 10:31 AM, Ray Morris <support@bettercgi.com> wrote: >> �My general scripting philosophy is that automation scripts that >> do not have errors should not generate output that will cause cron >> to send an email. > >> So... I grabbed the source code and started nosing around. > > So we'll look forward to seeing your patches I hope? This is the first time I've ever even looked at LVM source code. I'm not sure I can be trusted with patches. Thinking about it some more, I was wondering if the log_info macro is purely for syslog functionality. I could be barking up the wrong tree in terms of my suggested approach. I would rather leave this to someone with experience if the behavior can be agreed upon. > It does seem logical that it shouldn't produce informational > messages on stdout with --quiet. > > As to the first part, that got me thinking about the general rule. > Is it generally agreed that commands which do not have errors "should > not generate output" or that commands which do not have ERRORs "should > not generate output on standard ERROR? > > The OP said that these messages are on stdout, not stderr. �I'm > kind of thinking that's right. No errors, nothing on standard error. > If using --quiet, then no standard output. �If lacking a quiet option, > then cron jobs should redirect stdout to /dev/null, sending mail if > there are errors on stderr. �Thoughts? > -- > Ray Morris > support@bettercgi.com I agree completely with your assessment. The only issue I wanted to raise is that a quiet option is advertised, but it does not get the job done. Jeff > On Mon, 14 Feb 2011 09:46:05 -0600 > Jeff <jlar310@gmail.com> wrote: > >> Background: I am using lvm snapshots in a backup script. My general >> scripting philosophy is that automation scripts that do not have >> errors should not generate output that will cause cron to send an >> email. >> >> I am using Ubuntu 10.04 with lvm2.02.54-1ubuntu4. >> >> Even with the --quiet option I get "Logical volume <name> created" on >> stdout with lvcreate and "Logical volume <name> successfully removed" >> with lvremove. >> >> So... I grabbed the source code and started nosing around. In >> lv_manip.c, I find that these messages are produced with a call to the >> function log_print. log_print is a macro (in log.h) for >> LOG_LINE(_LOG_WARN, args). So it looks like the logging system sees >> these messages as warnings and is printing them even though verbosity >> is turned down as far as possible. In addition to --quiet on the >> command line, I have verbose = 0 in lvm.conf which according to the >> man page "should produce no output". >> >> >From my point of view, lv_manip.c should be calling the log_info >> >macro >> for these messages and not log_print, thus giving the user control >> over the output as advertised by the documentation. Disclaimer: I did >> not dig into the source code far enough to be assured that log_info >> will generated the proper results, but it certainly appears on the >> surface to be the right option. >> >> I also downloaded the latest source tarball (2.0.2.84) and the >> situation appears to be the same. >> >> Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-14 17:43 ` Jeff @ 2011-02-14 18:14 ` Alasdair G Kergon 2011-02-15 13:02 ` Jeff 0 siblings, 1 reply; 8+ messages in thread From: Alasdair G Kergon @ 2011-02-14 18:14 UTC (permalink / raw) To: Jeff; +Cc: linux-lvm The simple problem is that the code today does not distinguish between essential output (to stdout) and incidental output (to stdout). If I run 'pvs' I expect a list of PVs. If I run 'pvs --quiet' do I still expect to see that list? Today, there is no distinction: pvs output and the message you're wanting to suppress are the same category of message. The fix is to introduce a new macro alongside log_print so we can distinguish between the two cases, then have --quiet discard the incidental output and review every instance of log_print to see if it needs moving into the 'discard if quiet' category. Also provide an lvm.conf option to make --quiet the default for those who want that. etc. Alasdair ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-14 18:14 ` Alasdair G Kergon @ 2011-02-15 13:02 ` Jeff 2011-02-15 13:41 ` Mike Snitzer 0 siblings, 1 reply; 8+ messages in thread From: Jeff @ 2011-02-15 13:02 UTC (permalink / raw) To: linux-lvm On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk@redhat.com> wrote: > The simple problem is that the code today does not distinguish between > essential output (to stdout) and incidental output (to stdout). > > If I run 'pvs' I expect a list of PVs. > If I run 'pvs --quiet' do I still expect to see that list? > > Today, there is no distinction: pvs output and the message you're wanting > to suppress are the same category of message. Yes, there should be a difference between "do-something" commands and "tell-me-something" commands. I hope there aren't too many cases where that's a gray area. > The fix is to introduce a new macro alongside log_print so we can distinguish > between the two cases, then have --quiet discard the incidental output and > review every instance of log_print to see if it needs moving into the 'discard > if quiet' category. �Also provide an lvm.conf option to make --quiet the default > for those who want that. �etc. Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-15 13:02 ` Jeff @ 2011-02-15 13:41 ` Mike Snitzer 2011-02-15 16:07 ` Jeff 0 siblings, 1 reply; 8+ messages in thread From: Mike Snitzer @ 2011-02-15 13:41 UTC (permalink / raw) To: LVM general discussion and development On Tue, Feb 15 2011 at 8:02am -0500, Jeff <jlar310@gmail.com> wrote: > On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk@redhat.com> wrote: > > The simple problem is that the code today does not distinguish between > > essential output (to stdout) and incidental output (to stdout). > > > > If I run 'pvs' I expect a list of PVs. > > If I run 'pvs --quiet' do I still expect to see that list? > > > > Today, there is no distinction: pvs output and the message you're wanting > > to suppress are the same category of message. > > Yes, there should be a difference between "do-something" commands and > "tell-me-something" commands. I hope there aren't too many cases where > that's a gray area. Ignoring the fact that we have a --quiet option for a moment, why is the additional output of the command(s) so problematic? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-15 13:41 ` Mike Snitzer @ 2011-02-15 16:07 ` Jeff 2011-02-15 17:04 ` Mike Snitzer 0 siblings, 1 reply; 8+ messages in thread From: Jeff @ 2011-02-15 16:07 UTC (permalink / raw) To: LVM general discussion and development On Tue, Feb 15, 2011 at 7:41 AM, Mike Snitzer <snitzer@redhat.com> wrote: > On Tue, Feb 15 2011 at �8:02am -0500, > Jeff <jlar310@gmail.com> wrote: > >> On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk@redhat.com> wrote: >> > The simple problem is that the code today does not distinguish between >> > essential output (to stdout) and incidental output (to stdout). >> > >> > If I run 'pvs' I expect a list of PVs. >> > If I run 'pvs --quiet' do I still expect to see that list? >> > >> > Today, there is no distinction: pvs output and the message you're wanting >> > to suppress are the same category of message. >> >> Yes, there should be a difference between "do-something" commands and >> "tell-me-something" commands. I hope there aren't too many cases where >> that's a gray area. > > Ignoring the fact that we have a --quiet option for a moment, why is > the additional output of the command(s) so problematic? In short, the --quiet option isn't quiet. In the case of lvcreate and lvremove it prints purely informational confirmation messages to stdout. I find this somewhat inconsistent with other linux commands that offer a --quiet option (rsync for example). It's not so much problematic as it is an issue of good design and documentation. It's easy enough for me to send stdout to /dev/null in my scripts, but that does run the risk of missing important information in the case of unexpected results. What if the program isn't so precise about sending error messages to stderr? Of course that brings us back to the question of whether or not error-free cron jobs should generate mail, which could be a matter of opinion. Mine happens to be that they should not bother me unless there is a problem. As already stated, for commands such as lvcreate and lvremove where the user is requesting the lvm system to "do something" and not "tell me something" I think the --quiet option should actually make the program be quiet, which it does not in the current implementation. I am not a hard-core c developer and it's not likely that I would be able to find the time to contribute trustworthy patches. If the lvm-powers-that-be wish to ignore me, I can live with that. I simply saw a potential improvement and chose to share my thoughts. Jeff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet 2011-02-15 16:07 ` Jeff @ 2011-02-15 17:04 ` Mike Snitzer 0 siblings, 0 replies; 8+ messages in thread From: Mike Snitzer @ 2011-02-15 17:04 UTC (permalink / raw) To: LVM general discussion and development On Tue, Feb 15 2011 at 11:07am -0500, Jeff <jlar310@gmail.com> wrote: > On Tue, Feb 15, 2011 at 7:41 AM, Mike Snitzer <snitzer@redhat.com> wrote: > > On Tue, Feb 15 2011 at �8:02am -0500, > > Jeff <jlar310@gmail.com> wrote: > > > >> On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk@redhat.com> wrote: > >> > The simple problem is that the code today does not distinguish between > >> > essential output (to stdout) and incidental output (to stdout). > >> > > >> > If I run 'pvs' I expect a list of PVs. > >> > If I run 'pvs --quiet' do I still expect to see that list? > >> > > >> > Today, there is no distinction: pvs output and the message you're wanting > >> > to suppress are the same category of message. > >> > >> Yes, there should be a difference between "do-something" commands and > >> "tell-me-something" commands. I hope there aren't too many cases where > >> that's a gray area. > > > > Ignoring the fact that we have a --quiet option for a moment, why is > > the additional output of the command(s) so problematic? > > In short, the --quiet option isn't quiet. > > In the case of lvcreate and lvremove it prints purely informational > confirmation messages to stdout. I find this somewhat inconsistent > with other linux commands that offer a --quiet option (rsync for > example). > > It's not so much problematic as it is an issue of good design and > documentation. It's easy enough for me to send stdout to /dev/null in > my scripts, but that does run the risk of missing important > information in the case of unexpected results. What if the program > isn't so precise about sending error messages to stderr? well lvm _should_ send all errors to stderr. > As already stated, for commands such as lvcreate and lvremove where > the user is requesting the lvm system to "do something" and not "tell > me something" I think the --quiet option should actually make the > program be quiet, which it does not in the current implementation. Noted, definitely an lvm short-coming. > I am not a hard-core c developer and it's not likely that I would be > able to find the time to contribute trustworthy patches. If the > lvm-powers-that-be wish to ignore me, I can live with that. I simply > saw a potential improvement and chose to share my thoughts. Not ignoring you at all. This should get cleaned up. I was just pointing out that --quiet not actually being quiet isn't a showstopper at the moment -- so such a janitorial audit can be deferred. Thanks for the report, Mike ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-02-15 17:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-14 15:46 [linux-lvm] lvcreate and lvremove --quiet option is not quiet Jeff 2011-02-14 16:31 ` Ray Morris 2011-02-14 17:43 ` Jeff 2011-02-14 18:14 ` Alasdair G Kergon 2011-02-15 13:02 ` Jeff 2011-02-15 13:41 ` Mike Snitzer 2011-02-15 16:07 ` Jeff 2011-02-15 17:04 ` Mike Snitzer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.