Description of problem: /etc/logrotate.d/syslog shows postrotate /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true but for some reason this command doesn't work from logrotate., i.e. rsyslog keeps on writing to the old logfile. When I copy and paste the command to a root shell and execute, rsyslog takes the new logfile into use like it should, Version-Release number of selected component (if applicable): logrotate-3.9.1-2.fc23.x86_64 rsyslog-8.10.0-1.fc23.x86_64 How reproducible: I have now encountered this already on 2 consecutive Monday mornings, i.e. after the weekly logrotate run. Steps to Reproduce: 1. wait for the weekly logrotate run 2. check /var/log/messages 3. Actual results: rsyslog keeps on writing to the old logfile Expected results: rsyslog should write to the new /var/log/message Additional info: Maybe logrotate doesn't have the permissions to run "systemctl"?
Does it help to do this change? - /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true + /bin/kill -HUP $(cat /var/run/syslogd.pid 2> /dev/null) 2> /dev/null || true
I can report that I am seeing the exact same behavior. I'm running Fedora 23 Server. I first noticed the issue because fail2ban stops working, and I was investigating the sudden spike it failed login attempts. I found the following messages (there's one of these for every time logrotate runs) related to the inability of logrotate to run systemctl: messages-20151130:Dec 6 03:34:01 vin audit: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { stop } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/rsyslog.service" cmdline="/usr/bin/systemctl kill -s HUP rsyslog.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service#012 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Obviously, I'm running with SELinux in Enforcing mode. I'm not very good at reading SELinux messages, but it occurs to me that there are two possibilities for how SELinux restricts logrotate. It could be blocking access to systemctl, but it could also be blocking sending the HUP signal (through any channel) to rsyslogd. If it's the latter, then the suggested change won't help.
Thanks for checking the AVCs. I wonder why I didn't catch this; probably also ran it from a root shell. I think amending the SELinux policy would be the proper solution -> switching the component.
The problem is we miss a default labeling for /usr/lib/systemd/system/rsyslog.service together with appropriate rules.
Btw, the only releases affected are f23, f24.
commit e4637c2bbfffa5ec05b80248e94fd127661ad4bc Author: Lukas Vrabec <lvrabec> Date: Tue Jan 12 18:01:28 2016 +0100 Allow logrotate to systemctl rsyslog service. BZ(1284173)
selinux-policy-3.13.1-158.2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7cb7ac5cb9
selinux-policy-3.13.1-158.2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7cb7ac5cb9
Still doesn't work for me after updating to selinux-policy-targeted-3.13.1-158.2.fc23.noarch type=USER_AVC msg=audit(1453080721.624:377): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { stop } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/rsyslog.service" cmdline="/usr/bin/systemctl kill -s HUP rsyslog.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' # date --date= Mon Jan 18 03:32:01 EET 2016 # ls -lht /var/log/messages* -rw-r--r--. 1 root root 0 Jan 18 03:32 /var/log/messages -rw-r--r--. 1 root root 3.2K Jan 17 22:09 /var/log/messages-20160118 ... # lsof /var/log/messages* COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsyslogd 1037 root 65w REG 253,1 3232 136085 /var/log/messages-20160118
commit 7cc997acdfb2337b8cb46d30b2306be6d6999217 Author: Lukas Vrabec <lvrabec> Date: Mon Jan 18 13:01:19 2016 +0100 Fix SELinux context for rsyslog unit file. BZ(1284173) Fixed now, sorry for that.
Now that syslog rolled log files this morning, I can confirm Stefan Becker's results. I have selinux-policy-3.13.1-158.2.fc23.noarch and selinux-policy-targeted-3.13.1-158.2.fc23.noarch installed, I even rebooted after the install, and this morning when syslog rolled the log files this morning the renamed one remained in use. Lukas - when you say "Fixed now", does that mean it will be fixed in the next release of selinux-policy or that you have somehow released a new version of selinux-policy-3.13.1-158.2.fc23.noarch that we need to deploy?
Toby, Fixes are in this version: http://koji.fedoraproject.org/koji/buildinfo?buildID=712094
selinux-policy-3.13.1-158.2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
This bug was closed automatically by an update to selinux-policy-3.13.1-158.2.fc23, which didn't actually fix the issue, right? Can somebody confirm this is fixed with the latest stable update? There's .4 in the updates and .3 has been skipped, so the 'fixed in' field is probably wrong. Lukas, am I right?
Unfortunately, my logs went through logrotate automatically at 3:22:03 on Feb 7. At 6:58:53 on Feb 7, I ran dnf update and selinux-policy updated to .4. At 7:00:40, I manually HUPed rsyslogd to get syslogd using the new messages file. I'm not sure how to manually trigger logrotate in such a manner that the SELinux context would be sufficiently accurate to serve as a good test, so I'm waiting until Feb 14 to see logrotate run normally and I'll check to see if it properly rotates. I always know when it doesn't rotate, because fail2ban stops working! Log output: messages-20160207:Feb 7 03:22:03 vin audit: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { stop } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/rsyslog.service" cmdline="/usr/bin/systemctl kill -s HUP rsyslog.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service#012 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' dnf.rpm.log:Feb 07 06:58:53 INFO Upgraded: selinux-policy-3.13.1-158.4.fc23.noarch messages-20160207:Feb 7 07:00:40 vin rsyslogd: [origin software="rsyslogd" swVersion="8.10.0" x-pid="701" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
selinux-policy-3.13.1-158.4.fc23.noarch solves the problem for me. logrotate just went through the weekly cycle and rsyslog got huped: -rw-r--r--. 1 root root 6.6K Feb 15 03:21 /var/log/messages-20160215 -rw-r--r--. 1 root root 0 Feb 15 03:21 /var/log/messages Feb 15 03:21:01 XXXX rsyslogd: [origin software="rsyslogd" swVersion="8.10.0" x-pid="1052" x-info="http://www.rsyslog.com"] rsyslogd was HUPed The next message should go to /var/log/messages.
I can confirm as well that selinux-policy-3.13.1-158.4.fc23.noarch solves the problem for me: vin:root 5:30am /var/log# tail -n 1 messages-20160214 Feb 14 03:47:02 vin rsyslogd: [origin software="rsyslogd" swVersion="8.10.0" x-pid="674" x-info="http://www.rsyslog.com"] rsyslogd was HUPed vin:root 5:30am /var/log# head -n 1 messages Feb 14 03:48:02 vin audit: <message redacted>
*** Bug 1297253 has been marked as a duplicate of this bug. ***