logrotate does not compress /var/log/messages

Question

Over time I noticed some logs in /var/log such as auth, kern and messages were getting huge. I made logrotate entries for them:

$ cat /etc/logrotate.d/auth.log /var/log/kern.log { rotate 5 daily } $ cat /etc/logrotate.d/kern.log /var/log/kern.log { rotate 5 daily } $ cat /etc/logrotate.d/messages /var/log/messages { rotate 5 daily postrotate /bin/killall -HUP syslogd endscript } 

also I have the compress option enabled:

$ grep compress /etc/logrotate.conf # uncomment this if you want your log files compressed compress 

This works great for auth.log, kern.log and others, meaning that each of those logs is gzipped and rotated, with the last 5 days of logs retained. /var/log/messages however is not being compressed, resulting in way more than 5 days of logs:

$ ls /var/log/messages* /var/log/messages /var/log/messages-20100213 /var/log/messages-20100201 /var/log/messages-20100214 /var/log/messages-20100202 /var/log/messages-20100215 /var/log/messages-20100203 /var/log/messages-20100216 /var/log/messages-20100204 /var/log/messages-20100217 /var/log/messages-20100205 /var/log/messages-20100218 /var/log/messages-20100206 /var/log/messages-20100219 /var/log/messages-20100207 /var/log/messages-20100220 /var/log/messages-20100208 /var/log/messages-20100221 /var/log/messages-20100209 /var/log/messages-20100222 /var/log/messages-20100210 /var/log/messages-20100223 /var/log/messages-20100211 /var/log/messages-20100224 /var/log/messages-20100212 

As is explained in another logrotate question on ServerFault, the old logs are (most likely) not being removed because the file endings are different for each file. This appears to be because the files are not being gzipped.

What can I do to have /var/log/messages compressed and rotated with the last 5 days of logs retained just like all my other log files? What am I missing?

EDIT 1: additional information as requested in the first couple answers.

I'm running Gentoo Linux. My /etc/logrotate.conf file:

$ cat /etc/logrotate.conf # $Header: /var/cvsroot/gentoo-x86/app-admin/logrotate/files/logrotate.conf,v 1.3 2008/12/24 20:49:10 dang Exp $ # # Logrotate default configuration file for Gentoo Linux # # See "man logrotate" for details # rotate log files weekly weekly #daily # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rotated file dateext # uncomment this if you want your log files compressed compress # packages can drop log rotation information into this directory include /etc/logrotate.d notifempty nomail noolddir # no packages own lastlog or wtmp -- we'll rotate them here /var/log/wtmp { monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0600 root utmp rotate 1 } 

/etc/logrotate.d contains my custom config files as mentioned above along with configs for mysql, rsync, etc installed by those packages.

My root crontab is empty:

$ sudo crontab -l no crontab for root 

I checked all /etc/cron.{daily,hourly,monthly,weekly} for anything syslog related, and there's a script which rotates /var/log/syslog and /var/log/auth.log.

Next, I made a /var/log/messages-only logrotate config file as suggested by CarpeNoctem:

$ cat logrotate-messages weekly rotate 4 create dateext compress notifempty nomail noolddir /var/log/messages { rotate 5 daily postrotate /bin/killall -HUP syslogd endscript } 

Then I ran logrotate manually:

$ logrotate -d logrotate-messages -f reading config file logrotate-messages reading config info for /var/log/messages Handling 1 logs rotating pattern: /var/log/messages forced from command line (5 rotations) empty log files are not rotated, old logs are removed considering log /var/log/messages log needs rotating rotating log /var/log/messages, log->rotateCount is 5 dateext suffix '-20100224' glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' glob finding old rotated logs failed renaming /var/log/messages to /var/log/messages-20100224 creating new /var/log/messages mode = 0644 uid = 0 gid = 0 running postrotate script running script with arg /var/log/messages : " /bin/killall -HUP syslogd " compressing log with: /bin/gzip $ which gzip /bin/gzip $ file /bin/gzip /bin/gzip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 

According to the log above, logrotate compressed the log with /bin/gzip, but I don't see a compressed messages file in /var/log. Also, globbing for old rotated files failed.

EDIT 2: adding debug output of logrotate run after appending a .gz suffix to old /var/log/message-* files.

We start out with:

$ ls /var/log/messages* /var/log/messages /var/log/messages-20100222.gz /var/log/messages-20100219.gz /var/log/messages-20100223.gz /var/log/messages-20100220.gz /var/log/messages-20100224.gz /var/log/messages-20100221.gz 

Then run logrotate with our custom config file:

$ logrotate -d logrotate-messages -f reading config file logrotate-messages reading config info for /var/log/messages Handling 1 logs rotating pattern: /var/log/messages forced from command line (5 rotations) empty log files are not rotated, old logs are removed considering log /var/log/messages log needs rotating rotating log /var/log/messages, log->rotateCount is 5 dateext suffix '-20100224' glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' removing /var/log/messages-20100219.gz removing old log /var/log/messages-20100219.gz destination /var/log/messages-20100224.gz already exists, skipping rotation 

This time, logrotate's glob succeeds and finds the sixth compressed logfile, intending to remove it. The file isn't actually removed; I guess that's because we're running in debug mode.

I'm curious whether enabling the delaycompress option for /var/log/messages will help. I enabled it and will check the results the next morning.

Answer 1

Adding delaycompress to the configuration section for /var/log/messages solved the problem.

From man logrotate:

 delaycompress Postpone compression of the previous log file to the next rota‐ tion cycle. This only has effect when used in combination with compress. It can be used when some program cannot be told to close its logfile and thus might continue writing to the previ‐ ous log file for some time. 

I guess sysklogd, my syslog daemon, cannot be told to close its logfile, and thus this is necessary.

Interestingly, the original configuration I had (without the delaycompress directive), came straight out of man logrotate (except I changed weekly to daily):

 # sample logrotate configuration file compress /var/log/messages { rotate 5 weekly postrotate /usr/bin/killall -HUP syslogd endscript } 

Answer 2

It's hard to say with just this info, but I can tell you what has saved me a few times.

Logrotate has a debug option that will print a play-by-play of each step it takes to stdout. So in this case you could do:

logrotate -d /etc/logrotate.conf 

The output will tell you what exactly is going on. Also, if you want to narrow down the debug output you can do

logrotate -d /etc/logrotate.d/messages 

Though you may want to temporarily place the main logrotate.conf options in that files block since specifying the file directly means it will have never read the main configs options. Specifying the individual file also means you can use the -f (force) option in combination with the debug option to get a look at an actual rotation of the messages file taking place.

Answer 3

Consider trying this setting in your logrotate.conf:

dateformat .%Y%m%d 

and rename your existing messages files to use a dot instead of a dash. Then try your logrotate again.

The clues below led me to believe that the dash may be causing the glob to fail if it's being interpreted somehow as an option (where -- would fix this). It doesn't make sense, but it just might be possible.

dateext suffix '-20100224' glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' glob finding old rotated logs failed