Since Logrotate 3.8, which is default on Red Hat Enterprise Linux and CentOS 7, the parent permissions on your log directories play a vital role in whether or not logrotate will be able/willing to process your logs.
If your permissions allow writes by a group that isn’t root, you may see the following error when logrotate tries to run.
$ logrotate /etc/logrotate.d/something error: skipping "/var/www/vhosts/site.tld/logs/access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. error: skipping "/var/www/vhosts/site.tld/logs/error.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
A default logrotate config, that looks like this, can cause that problem.
$ cat /etc/logrotate.d/something
/var/www/vhosts/site.tld/logs/access.log {
create 0640 site_user httpd
compress
daily
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
It has the create statement, to recreate the logs with correct ownership/permissions, but that’s not sufficient for logrotate.
To resolve this problem, and have logrotate work properly again, you also have to add the su $user $group configuration. This causes logrotate to actually su - to that user and execute all logrotate actions as that user.
$ cat /etc/logrotate.d/something
/var/www/vhosts/site.tld/logs/access.log {
create 0640 site_user httpd
compress
daily
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
su site_user httpd
}
By adding a su site_user httpd in the example above, the same as the create config, logrotate can process the logs again with parent directories that have group permissions that allow groups other than root to write to those directories.