Bug 2012943
| Summary: | setroubleshoot logs chmod, chown and xml I/O errors on every boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mershl <mweires> |
| Component: | setroubleshoot | Assignee: | Petr Lautrbach <plautrba> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 35 | CC: | dwalsh, grepl.miroslav, mmalik, plautrba, travier, vmojzis |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | setroubleshoot-3.3.28-3.fc35 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-02-17 03:14:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
mershl
2021-10-11 17:01:51 UTC
Please run the following command and let us know what is the output: # ls -alZ /var/lib/setroubleshoot/ I'm NOT able to reproduce the problem on my Fedora 35 VM. Here is the output I see on my VM: # ls -alZ /var/lib/setroubleshoot/ total 12 drwx------. 2 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 4096 Oct 13 03:03 . drwxr-xr-x. 29 root root system_u:object_r:var_lib_t:s0 4096 Oct 13 03:01 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 Oct 13 03:03 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 2752 Oct 13 03:03 setroubleshoot_database.xml # # rpm -qa setr\* | sort setroubleshoot-plugins-3.3.14-3.fc35.noarch setroubleshoot-server-3.3.26-5.fc35.x86_64 # # ls -alZ /var/lib/setroubleshoot/ total 4 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 10. Okt 23:02 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 840 10. Okt 23:02 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 10. Okt 23:02 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 334 13. Okt 00:52 setroubleshoot_database.xml # rpm -qa setr\* | sort setroubleshoot-3.3.26-5.fc35.x86_64 setroubleshoot-plugins-3.3.14-3.fc35.noarch setroubleshoot-server-3.3.26-5.fc35.x86_64 I noticed the following warning is logged in addition: dbus-broker-launch[1811]: Service file '/usr/share//dbus-1/services/sealert.service' is not named after the D-Bus name 'org.fedoraproject.Setroubleshootd'. > I'm NOT able to reproduce the problem on my Fedora 35 VM.
Indeed. Just looked through journalctl and the first boot after installation of setroubleshoot shows the error, boots afterwards do no longer show it. That's also shown by the owner actually being setroubleshoot:setroubleshoot.
I've been testing it on Fedora Silverblue 35 - if it makes a difference for file ownerships in /var/...
Ohhh! Found something interesting on a Silverblue 34 machine. Here the error is logged every boot and... look at this: # ls -alZ /var/lib/setroubleshoot/ total 36 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 36380 17. Jan 2021 setroubleshoot_database.xml The same on a clean Fedora 34 installation: # ls -alZ /var/lib/setroubleshoot/ total 8 drwx------. 2 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 71 Oct 13 12:40 . drwxr-xr-x. 59 root root system_u:object_r:var_lib_t:s0 4096 Oct 13 12:36 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 Oct 13 12:40 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 239 Oct 13 12:40 setroubleshoot_database.xml Good catch! The ownership values of gnome-initial-setup:966 are definitely wrong. Try:
# echo "Z /var/lib/setroubleshoot - setroubleshoot setroubleshoot -" > /etc/tmpfiles.d/setroubleshoot.conf
# reboot
It should fix your problem (unless silverblue handles files in /etc/ specifically)
Hi Petr, This indeed fixed the issue (see log below). Thank you! Do you have a guess what could have caused this? Can I remove /etc/tmpfiles.d/setroubleshoot.conf afterwards? # ll /etc/tmpfiles.d/ total 0 # ls -alZ /var/lib/setroubleshoot/ total 36 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 gnome-initial-setup 966 system_u:object_r:setroubleshoot_var_lib_t:s0 36380 17. Jan 2021 setroubleshoot_database.xml # echo "Z /var/lib/setroubleshoot - setroubleshoot setroubleshoot -" > /etc/tmpfiles.d/setroubleshoot.conf # reboot # ls -alZ /var/lib/setroubleshoot/ total 32 drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 2. Dez 2020 . drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 798 15. Sep 19:20 .. -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 2. Dez 2020 email_alert_recipients -rw-------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 31030 13. Okt 19:17 setroubleshoot_database.xml $ journalctl -p4 -b | grep "cannot chown" <empty - The errors are no longer logged> Add: - /etc/tmpfiles.d/setroubleshoot.conf can be removed afterwards - If I understand tmpfiles.d correctly this is equivalent to running # restorecon and # chown on /var/lib/setroubleshoot/ recursively I guess this is caused by the way how setroubleshoot was installed.
How did you install it?
Using /etc/tmpfiles.d/setroubleshoot.conf was just a concept whether we could use the same line in /usr/lib/tmpfiles.d/setroubleshoot.conf and workaround this problem on every boot.
> - /etc/tmpfiles.d/setroubleshoot.conf can be removed afterwards
> - If I understand tmpfiles.d correctly this is equivalent to running #
> restorecon and # chown on /var/lib/setroubleshoot/ recursively
Yes, but it's run on every boot.
I installed it on Silverblue 34 & 35 using a simple `rpm-ostree install setroubleshoot`.
Now it gets interesting:
- Installed setroubleshoot on a freshly setup Silverblue 35 machine on 10th of October
- That's the machine I mentioned in a previous post: "the first boot after installation of setroubleshoot shows the error, boots afterwards do no longer show it. That's also shown by the owner actually being setroubleshoot:setroubleshoot."
- Looking into journalctl the error returned on 14th of October
- This machine is my main dev machine. It is rebooted at least once daily
- Assumption: 14th October could be the first "rpm-ostree update" after the initial installation of setroubleshoot
Anyway the owners are now:
# ls -alZ /var/lib/setroubleshoot/
total 4
drwx------. 1 setroubleshoot setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 98 10. Okt 23:02 .
drwxr-xr-x. 1 root root system_u:object_r:var_lib_t:s0 840 10. Okt 23:02 ..
-rw-------. 1 saslauth setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 0 10. Okt 23:02 email_alert_recipients
-rw-------. 1 saslauth setroubleshoot system_u:object_r:setroubleshoot_var_lib_t:s0 334 13. Okt 00:52 setroubleshoot_database.xml
I reported this problem at https://github.com/coreos/rpm-ostree/issues/3179 Pushed an initial set of updates in https://src.fedoraproject.org/rpms/setroubleshoot/pull-request/29 FEDORA-2022-611d8856d5 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-611d8856d5 FEDORA-2022-611d8856d5 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-611d8856d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-611d8856d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-611d8856d5 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. Can confirm the issue is fixed after updating to setroubleshoot-3.3.28-3.fc35.x86_64 |