Bug 100533

Summary: Design error: Logrotate does not'see' uncompressed files when in 'compress' mode
Product: [Retired] Red Hat Linux Reporter: David Tonhofer <bughunt>
Component: logrotateAssignee: Peter Vrabec <pvrabec>
Status: CLOSED CANTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: mattdm
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-18 14:43:35 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:

Description David Tonhofer 2003-07-23 06:48:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02

Description of problem:
When rotating logs with 'compress/delaycompress', logrotate does
not take into account any "uncompressed logs". This violates the
principle of least astonishment. At least for me.

In my case, I had a directory full of uncompressed logs:

  ssl_log.1 ssl_log.2 ssl_log.3 ssl_log.4 ssl_log.5 ssl_log.6

I then thought it would be useful to compress these logs because
space on the disk was getting scarce, so I added 'compress' and
'delaycompress' to the logrotate instructions. But I did not manually compress
the logs already there.

Surprise, surprise! After a certain time the following files existed:

  ssl_log.1 
  ssl_log.2.gz ssl_log.3.gz ssl_log.4.gz 
  ssl_log.2 ssl_log.3 ssl_log.4 ssl_log.5 ssl_log.6

i.e. 1) the last rotated file, not yet compressed ('delaycompress')
     2) the files rotated under the 'compress' regime
     3) the files rotated under the old 'not-compress' regime

What should intuitively have been there is:

  ssl_log.1 
  ssl_log.2.gz ssl_log.3.gz ssl_log.4.gz 
  ssl_log.5 ssl_log.6 ssl_log.7 ssl_log.8 ssl_log.9

Logrotate should not have a blind spot regarding any existing 
non-compressed files, it should *rotate them along*. This is 
especially important if someone uncompresses an old log file (e.g.
in order to check something), but then forgets to compress it again.
The uncompressed logfile will stay there in eternity and it will 
actually be missing in the sequence of files that are 'moved out' at 
the far end. This means that it might be missing in an archive.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Uncompress a file in the stream
2. Watch it remain in place

    

Actual Results:  See description

Expected Results:  See description

Additional info:

Comment 1 Elliot Lee 2003-07-24 16:45:04 UTC
You are responsible for manually compressing the logs already there.

Comment 2 David Tonhofer 2003-07-25 08:15:48 UTC
Awww...I thought it was good idea. *Anything* which takes away the possibility
of a foulup from the sysadmin is good, isn't it ;-)  Ah, well.


Comment 3 David Tonhofer 2004-10-03 14:15:30 UTC
This thing keeps bugging me.

Is anyone interested in a patch for this? 

For example, one could add an option 'lenient' that makes logrotate
try rotation of compressed or uncompressed logs.



Comment 4 Bill Nottingham 2006-08-05 04:22:39 UTC
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
provided.

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.


Comment 5 Bill Nottingham 2006-10-18 14:43:35 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.