CODEWITHSUNDEEP
emaillogrotate
Kiuki
Kiuki

Reputation: 644

How can I fix "/etc/cron.daily/logrotate: gzip: stdin: file size changed while zipping"?

in last days i get daily mail from cron's logrotate task:

/etc/cron.daily/logrotate:

gzip: stdin: file size changed while zipping

How can I fix it?

Thanks, Gian Marco.

Upvotes: 22

Views: 20574

Answers (2)

lamanux
lamanux

Reputation: 593

Here's a blog post in French which gives a solution.

In English, you can read this bug report.

To summarise:

  1. First you have to add the --verbose option in the script /etc/cron.daily/logrotate to have more information the next time it runs to identify which rotation log cause the problem.

    #!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate --verbose /etc/logrotate.conf`

  2. Next you have to add the delaycompress option in logrotate configuration.

    Like exemple, I add the nginx's logrotate configiguration in /etc/logrotate.d/nginx:

    /var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    ...
}

Upvotes: 27

Ztyx
Ztyx

Reputation: 14919

upstart will close (and reopen) its log file when it notices that the file is deleted. However, if you look at what gzip does, you see that it doesn't delete the file until after it's one writing the output file. That means that there always is a race condition where log lines might be lost for lines logs being written gzipping.

You can disable the warning using gzip --quiet, but really that doesn't hide the fact that you might still loose log lines.

This means that delaycompress is not a generic fix to this. It's a specific fix to a specific problem.

The real solution for this is probably a combination of delaycompress and being able to send a signal to the process. It will make the race condition go away in practise (unless you rotate multiple times per second :) ).

Upvotes: 5

Related Questions