Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On remote linux-based devices, I thought I'd use logrotate to manage any core files our appliance may create. But it seems logrotate considers every core file a unique file since the filename includes the PID. This breaks the way logrotate normally rotates files. E.g.:


Instead of seeing these as 3 variations of the same file, it sees this as 3 unique files. So if I had rotate 50 in /etc/logrotate.d/core, it would be willing to rotate through 50 different core_123 files, and 50 different core_222 files, etc., resulting in potentially hundreds or thousands of files. Instead, I want to ensure that logrotate manages a maximum of 50 core_* files.

This is the exact logrotate file I was trying to make work:

/mycores/core_* {
    maxage 28
    olddir /mycores/old
    rotate 50

I suspect this isn't possible with logrotate, but I figured I'd post on serverfault just in case I missed something in the documentation.

share|improve this question
Why are you generating core files in the first place? – Ignacio Vazquez-Abrams Nov 4 '10 at 4:00
That's a question for Stackoverflow. Since we have lots of software running on these devices and cannot control when something wrong is going to happen, we at least need to manage the cores (should they happen) so they don't eat up all the disk space. We do want to keep some recent cores to help us in debugging issues as they come up. – Stéphane Nov 4 '10 at 4:42
It might be easier to use something like find with a -mtime option to just delete things older then some time period. – Zoredache Nov 4 '10 at 5:16

We use a script like this. I don't see the point of involving logrotate as

  1. these are not log files
  2. you are not rotating them


EMAIL_TO="<%= mail %>"
EMAIL_SUBJ="Found core files on `hostname -s`"
DATETIME=`date +"%F-%H%M%S"`
EMPTY_CORE_FILES=`find /var/log/core/ -mmin +60 -type f -empty -not -name "*.gz" -not -name "*.zip" -print -exec rm {} \;`
CORE_FILES=`find /var/log/core/ -mmin +60 -type f -not -empty -not -name "*.gz" -not -name "*.zip"`

lockfile="/tmp/`basename $0`.lock"
lockfile -1 -r 5 -l 84600 ${lockfile} || exit 1
trap "/bin/rm -f $lockfile" EXIT INT TERM

for f in $CORE_FILES;
  gzip -9 $f

if [ $NUM_CORE_FILES != 0 ]

  mail "$EMAIL_TO" -s "$EMAIL_SUBJ" <<EOF
I found and gzipped $NUM_CORE_FILES on $HOSTNAME in /var/log/core, please investigate.

Files Found:

Empty Files:


share|improve this answer
up vote 1 down vote accepted

I combined logrotate with some shell magic to get the desired effect. Basically logrotate is still in charge of moving and compressing the files, and then kicking off the script needed to delete the old files as well as ensuring the directory doesn't have more than 50 or so files. Here is what I did:

/mycores/core_* {
    olddir /mycores/old
        # delete all core_*.gz files older than 28 days
        find /mycores/old -name "core_*.gz" -mtime +28 -delete
        # make sure we have a max of 50 files; delete the oldest files if we have too many
        for filename in $(find /mycores/old/ -name "core_*.gz" -printf "%T+ %p\n" | sort --reverse | tail --lines=+51 | cut -d' ' -f2); do rm $filename; sleep 0.5; done

I'm not the best bash scripter out there, so that postrotate script section might be heavier than necessary... :)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.