On Wed, 16 Dec 2015, Michael Gebetsroither wrote: > Package: logrotate > Version: 3.8.7-1+b1 > Followup-For: Bug #734688 > > Dear Maintainer, > > Seconded, the problem still persists in jessie. > Logrotate was practically broken after /var/log got full a month ago. > > There where various .log.1.gz files, most of which where 0 bytes which > stopped logrotate to act on those files completely. > > # grep 'error creating output file' logrotate_force_20151216.log > error: error creating output file /var/log/dpkg.log.1.gz: File exists > error: error creating output file /var/log/alternatives.log.1.gz: File exists > error: error creating output file /var/log/nginx/error.log.1.gz: File exists > error: error creating output file /var/log/nginx/access.log.1.gz: File exists > error: error creating output file /var/log/php5-fpm.log.1.gz: File exists > error: error creating output file /var/log/syslog.1.gz: File exists > error: error creating output file /var/log/daemon.log.1.gz: File exists > error: error creating output file /var/log/auth.log.1.gz: File exists > error: error creating output file /var/log/messages.1.gz: File exists
And in my case, it wasn't a 0 byte file - there was syslog.1 and syslog.1.gz, both largish. It is possible gzip simply failed the first time because I ran out of space. 2 observations: 1) logrotate didn't output any diagnostics, or exit non zero. Consequently, I noticed nothing in my cron.daily email for a month. I only noticed when a usb failure meant the syslog file grew enormously, and I saw the top of the messages were from a month prior. 2) All these suggestions of heuristics about deleting a file if 0 sized and created immediately before etc. Why not just, when logrotate finds a base file whose .gz already exists, recursively call itself again to start rotating down to the current file, which can then be compressed and resume where we were? Sorry no patches, already after my bedtime, and this has already been languishing in my todo list for a couple of weeks. -- Tim Connors
