Logrotate: permission denied on boot.log

logrotate fails to rotate /var/log/boot.log - searching points to SELinux and suggests adjustments that also include restorecon which appears to be a bad idea on Silverblue

systemctl status logrotate.service:

× logrotate.service - Rotate log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static)
     Active: failed (Result: exit-code) since Thu 2022-06-23 11:26:03 EDT; 6h ago
TriggeredBy: ● logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: 4923 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
   Main PID: 4923 (code=exited, status=1/FAILURE)
        CPU: 23ms

Jun 23 11:26:03 ghost.local systemd[1]: Starting logrotate.service - Rotate log files...
Jun 23 11:26:03 ghost.local logrotate[4923]: error: stat of /var/log/boot.log failed: Permission denied
Jun 23 11:26:03 ghost.local systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jun 23 11:26:03 ghost.local systemd[1]: logrotate.service: Failed with result 'exit-code'.
Jun 23 11:26:03 ghost.local systemd[1]: Failed to start logrotate.service - Rotate log files.

Any suggestions?

This warning is more strongly worded than it should be. It’s not a good idea to run restorecon on the entire system in Silverblue but it’s fine to use it to restore a context for a specific file.

Awesome - resolved then. Definitely read that as a never use it. Appreciate the answer!

Sadly, this problem still exist today. Every boot returns boot.log back to var_log_t.

1 Like

Can you open an issue in the Silverblue issue tracker? Thanks

I’ve filed an issue:

1 Like

issue-tracker

So far I have tracked this bug back to it’s original creation. It seems that var_log_t is the context given to /var/log/boot.log on a fresh installs of Silverblue and Kinoite, but not on Workstation. Further investigating is necessary in the installer.

Relabeling does fix this issue for the time being.

1 Like