All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.