On 2019-09-08 17:22:15 +0200, Christian Göttsche wrote: > Control: tags -1 moreinfo unreproducible > > The timestamp in the state file stands for the last attempt to rotate > the file (see https://github.com/logrotate/logrotate/issues/223), so > an update of it is fine. > > In message #27 logrotate probably did not show any error cause the > option 'daily' was used; when forcing a rotation (--force) an error > message is also shown in subsequently runs.
OK, I understand the reason with the upstream discussion. I think that the best thing is to try to reproduce the issue under the usual conditions (i.e. via cron and without trying to change the status file). So, on some machine, I've set in /var/log/apache2 touch -d 19040101 error.log error.log.1 so that I now have -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 [...] and let's see what happens. If I understand correctly, I should get an error each time cron.daily scripts will run, in particular tomorrow and the day after tomorrow. After confirming that, I can fix the timestamps manually. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)