Bug 23273 - logrotate goes berzerk and fills /var, uses all inodes
logrotate goes berzerk and fills /var, uses all inodes
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Preston Brown
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-04 03:14 EST by Need Real Name
Modified: 2007-04-18 12:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-21 16:34:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-01-04 03:14:53 EST
Logrotate (using version 3.3 here) can go haywire in /var/log/{mail,news}
and repeatedly gzip already .gzipped files.  This results in an
inordinately large number of gzipped files, consuming all inodes and 
filling /var (using a 380Mb /var here).  This has been confirmed by
a number of other users.

My hypothesis is that setting permissions of 600 on the directory
(which some installations appear to do) causes this behavior.  It could
be a more fundamental logrotate problem, however.

enjoy.

rick
Comment 1 Preston Brown 2001-06-21 16:01:41 EDT
Can you give us a little bit more information on this bug?  In the environment where 
you are having this problem, run "logrotate -v" and attach the output to the bug 
report.
Comment 2 Need Real Name 2001-06-21 16:34:47 EDT
I don't have logrotate running in those environments any more due to this
problem.  I'd find /var full (and these were 512MB /var partitions) due to
/var/log/{mail,news} being filled with thousands and thousands of files named
like:

mail.1.gz.2.gz.1.gz.2.gz
mail.1.gz.2.gz.1.gz.2.gz.1.gz

[and on out with something like 15 gz's in a single name]

It looked to me like logrotate was versioning and gzipping
files it had already versioned and gzipped.  I thought perhaps
the directory permissions (0600) had something to do with it, but
ultimately even changing them to 700 or even 755 didn't seem to
alleviate the problem.

Ultimately I moved to a pair of centralized loghosts running FreeBSD
and using a custom rotation and summarization script instead of logrotate.

Sorry I can't be more helpful.

Rick Bradley (rick@eastcore.net)
Comment 3 Preston Brown 2001-08-24 10:16:07 EDT
Thanks for trying.  We haven't been able to duplicate this and there have been 
no other reports of such behaviour, so I have to assume it is a very esoteric 
bug related somehow to the environment that had been set up.

Note You need to log in before you can comment on or make changes to this bug.