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
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.
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)
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.