I see that the logrotate service has failed to start from within cockpit. In there it explains that this is due to improper permissions on /var/log/sssd directory. After a sudo chmod 755 /var/log/sssd I can start the logrotate service without issues. Pretty sure what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory. Reproducible: Always Steps to Reproduce: 1.Apply system updates that include sssd, have a look at services in cockpit 2.after seeing the logrotate service failed to start using sudo chmod 755 /var/log/sssd 3.clear the error, and start logrotate and it works as it should Actual Results: Well, the steps above get logrotate running again. I am not sure how this may effect the sssd system itself though Expected Results: it is expected to see logrotate service running without the need to use sudo chmod 755 /var/log/sssd
> In there it explains that this is due to improper permissions on /var/log/sssd directory. Could you please quote error message/log? > what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory Depending on specific configuration, SSSD might need this folder to be group-writeable.
logrotate error: skipping "/var/log/sssd/sssd_kcm.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.
Could you please check if addition of a line ``` su sssd sssd ``` to `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) resolves an issue for you?
(In reply to Alexey Tikhonov from comment #3) > Could you please check if addition of a line > ``` > su sssd sssd > ``` > to `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) > resolves an issue for you? root@sponix:/etc/logrotate.d# cat sssd /var/log/sssd/*.log { weekly missingok notifempty sharedscripts rotate 2 compress delaycompress su sssd sssd postrotate /bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || true /bin/pkill -HUP sssd_kcm 2> /dev/null || true endscript } within cockpit it no longer has the permission error given prior. But it still doesn't actually keep the logrotate service running either. 8:23 PM Finished logrotate.service - Rotate log files. systemd 8:23 PM logrotate.service: Deactivated successfully. systemd 8:23 PM Starting logrotate.service - Rotate log files... Maybe this is a user error. I feel that logrotate service is supposed to keep running. Is this wrong of me?
(In reply to Alexey Tikhonov from comment #1) > > In there it explains that this is due to improper permissions on /var/log/sssd directory. > > Could you please quote error message/log? > > > what I've done to resolve this is take the permissions from drwxrwxr-x to drwxr-xr-x on this directory > > Depending on specific configuration, SSSD might need this folder to be > group-writeable. I can get you any logging you would like to see. Just give me a command to dig it up, and I'll attach it.
(In reply to sponix2ipfw from comment #4) > (In reply to Alexey Tikhonov from comment #3) > > Could you please check if addition of a line > > ``` > > su sssd sssd > > ``` > > to `/etc/logrotate.d/sssd` (inside {}, for example after "compress" line) > > resolves an issue for you? > > root@sponix:/etc/logrotate.d# cat sssd > /var/log/sssd/*.log { > weekly > missingok > notifempty > sharedscripts > rotate 2 > compress > delaycompress > su sssd sssd > postrotate > /bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || > true > /bin/pkill -HUP sssd_kcm 2> /dev/null || true > endscript > } > > within cockpit it no longer has the permission error given prior. But it > still doesn't actually keep the logrotate service running either. > > 8:23 PM > Finished logrotate.service - Rotate log files. > systemd > 8:23 PM > logrotate.service: Deactivated successfully. > systemd > 8:23 PM > Starting logrotate.service - Rotate log files... > > Maybe this is a user error. I feel that logrotate service is supposed to > keep running. Is this wrong of me? Frankly, I don't know. Jan, could you please help here?
I think that the following change might be the root cause of your issue: https://github.com/logrotate/logrotate/pull/560 https://github.com/logrotate/logrotate/commit/47f79e71b8e9f723b83081c3ddf74224f598610f Change is included in logrotate-3.22.0
Jan, (1) is logrotate service supposed to keep running all the time or is behavior mentioned in comment 4 - expected? (2) do you think my proposal in comment 3 is a proper solution when log dir is non-root-group writable?
> (1) is logrotate service supposed to keep running all the time or is > behavior mentioned in comment 4 - expected? Rotation is based on the systemd timer. By default, it happens once per day. > (2) do you think my proposal in comment 3 is a proper solution when log dir > is non-root-group writable? Yes, this should be the way to go. From the man page: ``` If the user/group you specify here does not have sufficient privilege to make files with the ownership you've specified in a create directive, it will cause an error. If logrotate runs with root privileges, it is recommended to use the su directive to rotate files in directories that are directly or indirectly in control of non-privileged users. ```
(In reply to Jan Macku from comment #9) > > (1) is logrotate service supposed to keep running all the time or is > > behavior mentioned in comment 4 - expected? > > Rotation is based on the systemd timer. By default, it happens once per day. > > > (2) do you think my proposal in comment 3 is a proper solution when log dir > > is non-root-group writable? > > Yes, this should be the way to go. From the man page: Thank you for the confirmation.
Upstream PR: https://github.com/SSSD/sssd/pull/7512
Pushed PR: https://github.com/SSSD/sssd/pull/7512 * `master` * e4ae4d6129e85fe99bbb82438ed90352400ecdf3 - BUILD: configure logrotate to work with non-root-group writable folder
Any chance we can get an upstream release so we can get this fix in Fedora 41?
*** Bug 2315854 has been marked as a duplicate of this bug. ***
*** Bug 2316165 has been marked as a duplicate of this bug. ***
Gentle ping here. It would be great to get this in Fedora 41 before the freeze next week. Thanks
FEDORA-2024-73827b9035 (sssd-2.10.0-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-73827b9035
FEDORA-2024-73827b9035 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-73827b9035` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-73827b9035 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I installed the update and logrotate.service now works fine here F41.. Karma left.
FEDORA-2024-73827b9035 (sssd-2.10.0-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.