Please share your current setup:
Debian version: (old-stable | stable | testing | unstable)
Logrotate version: (logrotate --version)
Please share your cronjob config '/etc/cron.daily/logrotate'
Are you using systemd?
    If yes, please share 'systemctl status logrotate.timer' and
'journalctl -u logrotate' (the most recent part of it).


> It seems really broken, worse than expected. First, I did not get
> any error via cron, and the error logs did not change:
>
> -rw-r----- 1 root adm 306 1904-01-01 00:00:00 error.log
> -rw-r----- 1 root adm 440 1904-01-01 00:00:00 error.log.1
> -rw-r----- 1 root adm 271 2019-09-16 00:00:02 error.log.2.gz
> -rw-r----- 1 root adm 269 2019-09-15 00:00:02 error.log.3.gz
> -rw-r----- 1 root adm 271 2019-09-14 00:00:02 error.log.4.gz
> -rw-r----- 1 root adm 271 2019-09-13 00:00:01 error.log.5.gz
> [...]

That the logs do not change is expected, as gzip failed;
if you using systemd you should see some error messages in the journal.

> Worse, this seemed to have interrupted the rotation of the
> access logs (or is this a different bug?):
>
> -rw-r----- 1 root adm 308 2019-09-17 16:39:00 access.log
> -rw-r----- 1 root adm 156 2019-09-16 16:31:06 access.log.2.gz
> -rw-r----- 1 root adm 157 2019-09-13 12:36:03 access.log.3.gz
> -rw-r----- 1 root adm 155 2019-09-12 12:25:14 access.log.4.gz
> -rw-r----- 1 root adm 156 2019-09-10 10:33:38 access.log.5.gz
> [...]

This is indeed unexpected, in my tests logrotate continues to rotate
other logs. (see https://paste.debian.net/1101399/)


p.s.:
To avoid these timestamps you can use the configuration option 'prerotate'.
Otherwise it's on gzip.

Reply via email to