Cron Daemon <root@aluminium.wikimedia.org> 7:25 AM (1 hour ago) to root /etc/cron.daily/logrotate: error: error opening /var/log/squid3/access.log.1.gz: No such file or directory run-parts: /etc/cron.daily/logrotate exited with return code 1
In this case access.log.1.gz was present on disk and its content was bigger than zero bytes. I had to manually gzip it.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| operations/puppet | production | +1 -1 | Increase the squid's logrotate log retention to 2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T294906 Puppet Improvements 2021/2022 | |||
| Open | jbond | T265138 Work required to prepare for puppet 6 | |||
| Open | None | T273673 replace all puppet crons with systemd timers | |||
| Open | None | T132324 Tracking and Reducing cron-spam to root@ | |||
| Open | None | T153940 Logrotate fails for: "$FILE No such file or directory" |
Change 342586 had a related patch set uploaded (by Elukey):
[operations/puppet] Increase the squid's logrotate log retetion to 2
Change 342586 merged by Elukey:
[operations/puppet] Increase the squid's logrotate log retention to 2
I had a variant of this during clinic
/etc/cron.daily/logrotate: error: error creating output file /var/log/squid3/access.log.1.gz: File exists run-parts: /etc/cron.daily/logrotate exited with return code 1
This is caused when logrotate has a problem between the compress and move stage. the logrotate action would be something like
rm /var/log/squid3/access.log.2.gz gzip /var/log/squid3/access.log.1 mv /var/log/squid3/access.log.1.gz /var/log/squid3/access.log.2.gz mv /var/log/squid3/access.log /var/log/squid3/access.log.1
if something happens between steps 2 and three then /var/log/squid3/access.log.1.gz gets left behind and the next time logrotate tries todo step 2 it fails