Verbose mode should use STDOUT, not STDERR

[orev]

Verbose mode should send messages to STDOUT, not STDERR. This enables capturing non-error messages in log files while allowing errors to be received as email alerts when run as a cron job. Also conceptually, verbose messages are not errors, so they should not be placed on STDERR.

[glensc]

why this is good: if output is logged to stdout, i could logrotate -v | less

[kdudka]

This is how logging is currently implemented:
https://github.com/logrotate/logrotate/blob/73f78069/log.c#L83

There is just one stream (currently stderr) for all messages above the specified log level. Apart from that, you can use the -l option to specify a file to log all messages to.

I see no real benefit in unconditionally changing the output stream from stderr to stdout now. The example in question could be easily changed to logrotate -v 2>&1 | less.

[orev]

@kdudka Your comment does not address this request. No one said that logging should "unconditionally" go to stderr instead of stdout, and a shell redirection tutorial is not helpful or appropriate. The point is to separate informational messages from error messages, which is a well established concept.

The request is to have error messages go to stderr, and log/verbose messages go to stdout. This enables the extremely common idiom where the program runs from cron (which is pretty much always the case for logrotate), and regular logging occurs to a file while errors go to stderr, which can then be caught by cron and emailed out as an alert that something went wrong. Currently there is no way to automatically distinguish if output is an error or information.

If that takes more effort than making a simple change to the message() function, then so be it. Each call to message() would need to be reviewed and decided if it is an error or info, and updated accordingly.

[kdudka]

On Tuesday, September 20, 2016 09:00:26 orev wrote:

@kdudka Your comment does not address this request. No one said that
logging should "unconditionally" go to stderr instead of stdout, and a
shell redirection tutorial is not helpful or appropriate. The point is to
separate informational messages from error messages, which is a well
established concept.

By "unconditionally" I meant "enabled by default". We try to avoid changes
in behavior where possible, especially when something works consistently for
a long period of time and users may already rely on the current behavior.

The request is to have error messages go to stderr, and log/verbose
messages go to stdout. This enables the extremely common idiom where the
program runs from cron (which is pretty much always the case for
logrotate), and regular logging occurs to a file while errors go to
stderr, which can then be caught by cron and emailed out as an alert
that something went wrong. Currently there is no way to automatically
distinguish if output is an error or information.

This request (which is orthogonal to what @glensc requested) is to some
extent already addressed by the -l option (used instead of -v). Is not it?

On Linux, you can use something like logrotate -l /dev/fd/1.

If that takes more effort than making a simple change to the message()
function, then so be it. Each call to message() would need to be
reviewed and decided if it is an error or info, and updated accordingly.

It is not about code changes really. It is about changing an interface
that has already been exposed to users for a long period of time.

[orev]

I suggest that for any 4.0 release that might come, this change be made so logrotate follows the well-established convention of info on stdout, and errors on stderr. Using -l /dev/fd/1 might work, but it's certainly not typical or obvious, and is more of a workaround rather than a fix.

[kdudka]

I do not think that such a convention applies generally. There are many programs out there that output info/progress/diagnostic messages to stderr, regardless severity of the messages being printed (curl, gcc, tar, ...).

[orev]

I don't want to be arguing on here, but I really find it hard to accept the assertion that the convention of stdout and stderr is not a concept that applies generally. I mean, the entire concept is built right into the name of each output stream. It doesn't get any more obvious, and I really can't believe that I need to be arguing this. Whether other programs do it incorrectly, are used in special contexts, or have some very old legacy reasons for it aren't good examples.

The context for logrotate is very specifically, almost exclusively, to run through cron which has very specific expectations and behaviors depending on how output is generated. Such behavior is critical for sysadmins to determine the status of the log rotation (i.e. if something fails they need to know). It's not an interactive thing that can fudge the stdout/stderr concept to fit special interactive usage scenarios.

[cedricyaal]

I am also really surprised by this behaviour. I would have expected that only error will go to stderr and all others go to stdout.

[kdudka]

I think neither the current nor the proposed behavior would please everyone. On top of that, changing the behavior in an update of logrotate is a no-go I think. Would it help if we introduced a new configuration and/or command line option to enable the proposed behavior?

[cedricyaal]

@kdudka yes i would help a lot thanks.

[Jonathan-LeRoux]

I was also very surprised when I started getting emails from cron after adding the --verbose option.
logrotate does not say what kind of error it encountered without --verbose. I was hoping to catch more info on the error that's bothering our system next time it occurs, so I added --verbose, and I now we get emails every single day. I thought I'd be clever and use cronic to wrap around logrotate and avoid getting emails when there's no error, but I just realized that logrotate dumps every message in stdout anyway.
I couldn't agree more with @orev. Error messages should be sent to stderr, while non-error messages should be sent to stdout.
The proposed workarounds are not clean fixes, they are just hacks.

[iliv]

Yeah, @orev has a good point. This is conceptually correct and behavior contrary to this concept always make my eyebrows go up (logrotate or not).