<div dir="ltr"><br>We have a bunch of new(ish) Debian 10 VMs, and logrotate is failing to rotate our non-standard logs.  Unfortunately we deleted all the old Debian 9 VMs before I noticed this problem, so they're not readily available for comparison.  The logrotate config files worked fine on Debian 9 (provisioning is with Ansible, so it's consistent).  The failures aren't detailed enough to help.  Here's the config:<br><br>    # /etc/logrotate.d/ruby<br>    /opt/rubyapp/log/*.log {<br>            daily<br>            missingok<br>            rotate 28<br>            compress<br>            delaycompress<br>            copytruncate<br>    }<br><br>The parent configuration is standard Debian 10:<br><br>    # /etc/logrotate.conf<br>    # (system-supplied comments removed)<br>    weekly<br>    rotate 4<br>    create<br>    include /etc/logrotate.d<br><br>Unfortunately my paranoia is such that I'm redacting or modifying machine names and folder names ... I apologize for that.  But I don't think the path involved is the problem.<br><br>Here's one of the errors:<br><br>    # systemctl status logrotate.service<br>    ● logrotate.service - Rotate log files<br>       Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)<br>       Active: failed (Result: exit-code) since Thu 2019-10-17 00:00:17 EDT; 12h ago<br>         Docs: man:logrotate(8)<br>               man:logrotate.conf(5)<br>      Process: 29004 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)<br>     Main PID: 29004 (code=exited, status=1/FAILURE)<br><br>    Oct 17 00:00:01 acctserver systemd[1]: Starting Rotate log files...    <br>    Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/newrelic_agent.log.1 for compression<br>    Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/puma.stderr.log.1 for compression<br>    Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/puma.stdout.log.1 for compression<br>    Oct 17 00:00:14 acctserver logrotate[8621]: error: unable to open /opt/rubyapp/log/traffic.log.1 for compression<br>    Oct 17 00:00:17 acctserver systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE<br>    Oct 17 00:00:17 acctserver systemd[1]: logrotate.service: Failed with result 'exit-code'.<br>    Oct 17 00:00:17 acctserver systemd[1]: Failed to start Rotate log files.<br><br>Here's the folder contents:<br><br>    # cd /opt/rubyapp/log<br>    # ls -l<br>    -rw-rw-r--+ 1 root root        1982 Oct 16 15:08 newrelic_agent.log<br>    -rw-rw-r--+ 1 root root        7194 Oct 16 13:37 newrelic_agent.log.1<br>    -rw-rw-r--+ 1 root root        2549 Oct 10 17:45 newrelic_agent.log.2.gz<br>    -rw-rw-r--+ 1 root root      154290 Oct 17 12:34 puma.stderr.log<br>    -rw-rw-r--+ 1 root root      573253 Oct 16 13:37 puma.stderr.log.1<br>    -rw-rw-r--+ 1 root root      512648 Oct 10 17:45 puma.stderr.log.2.gz<br>    -rw-rw-r--+ 1 root root         238 Oct 16 15:08 puma.stdout.log<br>    -rw-rw-r--+ 1 root root         722 Oct 16 13:37 puma.stdout.log.1<br>    -rw-rw-r--+ 1 root root         701 Oct 10 17:45 puma.stdout.log.2.gz<br>    -rw-rw-r--+ 1 root root  4747006453 Oct 17 12:37 traffic.log<br>    -rw-rw-r--+ 1 root root 15668065757 Oct 10 17:55 traffic.log.1<br>    -rw-rw-r--+ 1 root root   850646513 Sep 20 18:12 traffic.log.2.gz<br><br>I note that in /var/log/ - where logrotate continues to work fine - that files are owned mostly root:adm (what is 'adm', and does it matter in this context?) and the permissions are 640 rather than 664.  There are ACLs attached to the files/folder shown above ... does _that_ matter?  Where this gets weirder is that if I run 'logrotate --force /etc/logrotate.d/ruby' it gets rotated fine.  It runs fine if run by hand, it fails if run on a SystemD timer.  Which suggests a difference in permissions, but don't timers run as root:root?<br><br>Any thoughts appreciated.  As you can see, these are damn big logs, and we have this problem across multiple machines so I'd really like to fix it ...<br><br>Errors on other servers aren't always consistent with this: a fix for this may or may not help with them, so I may be coming back for more.<br><br>Thanks all.<div><div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Giles<br><a href="https://www.gilesorr.com/" target="_blank">https://www.gilesorr.com/</a><br><a href="mailto:gilesorr@gmail.com" target="_blank">gilesorr@gmail.com</a></div></div></div></div>