Bug 722209

Summary:	/etc/cron.daily/logrotate should not suppress messages and is not marked as a configuration file
Product:	Red Hat Enterprise Linux 6	Reporter:	Robert Vogelgesang <vogel>
Component:	logrotate	Assignee:	Jan Kaluža <jkaluza>
Status:	CLOSED ERRATA	QA Contact:	Tomas Dolezal <todoleza>
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.1	CC:	dnovotny_bugzilla, ejtr, jorton, mmaslano, moshiro, ovasik, pchavan, psklenar
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	logrotate-3.7.8-18.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	722825 1174207 (view as bug list)		Environment:
Last Closed:	2015-07-22 06:19:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	722825, 782183, 994246, 1075802, 1174207

Description Robert Vogelgesang 2011-07-14 16:01:47 UTC

Description of problem:
The daily cronjob of logrotate redirects all error (and other) messages to /dev/null. Throwing away error messages is the most stupid thing one can do if you want a reliable system and therefore need detailed error reports in case something goes wrong.

The ALERT logged to syslog is not enough, because there is no indication of what did go wrong or why something failed.

If you do not want cron -- or anacron, for that matter -- to send an email, then log _all_ messages, including those coming from pre- and postrotate scripts.

A big WARNING to anyone who wants to fix the issue by editing /etc/cron.daily/logrotate: This file is not marked as a configuration file in the RPM, which means your changes will be overwritten when the next update RPM is installed.

Version-Release number of selected component (if applicable):
logrotate-3.7.8-12.el6_0.1.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Just look at /etc/cron.daily/logrotate and notice the redirection.
2. Modify /etc/cron.daily/logrotate and install an update RPM of logrotate, and your changes are lost, without warning.
3.

Actual results:
Error messages of logrotate itself or from any pre- or postrotate scripts are lost.

Expected results:
All messages should be mailed to the root user.

Additional info:
The mail configuration option does not help, because I don't want the logs, but only error messages.

I notice that the Fedora 14 version of logrotate suffers from the same problem, so maybe this comes from upstream, but it definitely should be fixed for the Enterprise level.

Comment 2 RHEL Program Management 2011-07-14 16:18:49 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Jan Kaluža 2011-07-18 08:13:27 UTC

You are right, it's upstream change. I really don't understand why he changed it in https://fedorahosted.org/logrotate/changeset/268/trunk/examples/logrotate.cron . Thanks for report.

Comment 4 Daniel Novotny 2011-09-29 10:07:01 UTC

Hello,

The redirection change was in order to solve Bug 517321
Another instance of this behavior is Bug 542538

Comment 5 Jan Kaluža 2011-09-29 10:12:29 UTC

Thanks for info Dan. I will check those bugs.

Comment 6 Robert Vogelgesang 2011-09-29 11:46:08 UTC

(In reply to comment #4)
> Hello,
> 
> The redirection change was in order to solve Bug 517321
> Another instance of this behavior is Bug 542538

IMHO, these bugs are bugs of run-parts (in the crontabs package) and not of logrotate.

Instead of using the pipe to awk in run-parts, the output of each command could be redirected to a temporary file, and if that is not empty after the command finished, run-parts would print the command name followed by the contents of the temporary file, and the temporary file should then be removed.

To avoid issues with output from longer running processes started by logrotate, a new temporary file should be created for each command started by run-parts.

run-parts should be fixed, because other scripts in /etc/cron.* could expose the same behaviour as logrotate, i. e. starting long-running processes that keep open stderr and/or stdout.

I've submitted Bug #742206 for the crontabs package, referencing this Bug here.

Comment 8 Jan Kaluža 2011-12-09 09:34:02 UTC

Ok, it looks we have two options how to "fix" it in logrotate and none of them
look right:

1. Keep the output redirection as it is now, and suppress error messages.
2. Remove the redirection and wait for someone with the same problem as in Bug
517321 to find out which daemon is causing run-parts to freeze. This will
probably cause a regression in the future, but hopefully we would be able to
find out which daemon is broken.

I will try to ask reporter of Bug 517321 if he remembers which services he ran
or if he still have that machine and can provide us list of config files in
/etc/logrotate.d directory to have at least some tips for packages which could
be broken this way.

Comment 9 Robert Vogelgesang 2011-12-09 10:33:56 UTC

(In reply to comment #8)
> Ok, it looks we have two options how to "fix" it in logrotate and none of them
> look right:
> 
> 1. Keep the output redirection as it is now, and suppress error messages.
> 2. Remove the redirection and wait for someone with the same problem as in Bug
> 517321 to find out which daemon is causing run-parts to freeze. This will
> probably cause a regression in the future, but hopefully we would be able to
> find out which daemon is broken.

I'd certainly go with the second option, We are running all of our important RHEL-6 machines this way.  run-parts does not freeze, and the only messages we get from the logrotate daily cronjob are all coming from postrotate scripts that we hacked ourselves (which is good, IMHO).

So, either we don't have the "misbehaving" package installed on our machines, or the original issue is fixed already.

 
> I will try to ask reporter of Bug 517321 if he remembers which services he ran
> or if he still have that machine and can provide us list of config files in
> /etc/logrotate.d directory to have at least some tips for packages which could
> be broken this way.

Additionally you could mark /etc/cron.daily/logrotate with %config(noreplace) in the spec file, to make it easier for local system admins to "fix" such issues in a way they see as appropriate.

Comment 14 Tom Lavigne 2012-09-18 15:24:35 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.
    
Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 18 Jan Kaluža 2012-12-04 06:11:47 UTC

*** Bug 878032 has been marked as a duplicate of this bug. ***

Comment 21 RHEL Program Management 2013-10-14 01:03:01 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 22 Robert Vogelgesang 2013-11-21 11:08:24 UTC

(In reply to RHEL Product and Program Management from comment #21)
> This request was evaluated by Red Hat Product Management for
> inclusion in the current release of Red Hat Enterprise Linux.
> Because the affected component is not scheduled to be updated
> in the current release, Red Hat is unable to address this
> request at this time.

Apparently, the Red Hat Product Management doesn't really know what their engineering does.  The logrotate package actually was updated just now, together with the RHEL-6.5 update, and is now at version 3.7.8-17.el6.

But a fix for this simple but annoying issue was not included.  Why?  Fedora has it fixed since ages now.

Comment 28 errata-xmlrpc 2015-07-22 06:19:32 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1293.html