Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #11855] logrotate uses incorrect group on CentOS 7 #4240
This issue has been migrated from Redmine: https://dev.icinga.com/issues/11855
Created by rbu on 2016-05-29 09:31:40 +00:00
logrotate errors on the first day:
Then, on subsequent days, it errors with:
The directory after the logrotate run looks like this:
The user ids are as follows:
The logorate script contains:
The root of the problem seems to be the following: Icinga, when started for the first time and at every service restart (with systemctl), will ensure that its log file is owned by icinga:icingacmd (994:991). logrotate changes to icinga:icinga (994:992) and performs the following actions:
That is where it fails.
My first guess for a resolution would be that if icinga2 wants the group to be icingacmd, then the logrotate recipe must use that group too.
This issue is a reoccurrence of #8868, but due to another cause it seems to me.
Updated by dgoetz on 2016-06-01 14:17:51 +00:00
So the create directive is wrong when Icinga 2 expects ownership icinga:icingacmd, but this is only for creation of the new file after rotation and before the postscript.
Can you try "su icinga icingacmd" in the logrotation and if it works fine?
Also I am quite not sure if the su directive is required at all. Typically it is used to avoid insecure privileges Icinga 2 does not assign to the log directory.
Updated by mfriedrich on 2016-06-06 15:58:02 +00:00
That's the config of a fresh centos Docker container with icinga2 v2.4.10 installed.
I would rather suspect the package setting the wrong directory ownership (icinga:icingacmd) for /var/log/icinga2 which somehow influences the file creation/rotation here in combination with SELinux.
Updated by rbu on 2016-06-07 20:01:32 +00:00
I can confirm that is the same configuration I had a problem with. Can you reproduce the issue in your container?
I can also confirm now that setting this config fixes the bug:
The system in question has SELinux disabled. The problem is that icinga changes the file ownership (group) when it is restarted.
I understand that running as user "icinga", logrotate should have the permission to write to the directory in question. So no idea why this happens.
Sorry for that double post.
This logrotate config works for me on SLES 12 SP1:
It's a slightly modified version of the config which ships with the official package.
I get a similar issue on Ubuntu 16.04 :