Red Hat Bugzilla – Bug 901812
[abrt] systemd-197-1.fc18.1: crash: Process /usr/lib/systemd/systemd was killed by signal 7 (SIGBUS)
Last modified: 2013-03-16 21:00:01 EDT
Version-Release number of selected component:
cmdline: /usr/lib/systemd/systemd --switched-root --system --deserialize 32
Thread no. 1 (10 frames)
#1 crash at src/core/main.c:137
#3 pcre_exec at pcre_exec.c:6409
#4 lookup at label_file.c:618
#5 selabel_lookup_common at label.c:197
#6 selabel_lookup_raw at label.c:233
#7 label_mkdir at src/shared/label.c:267
#8 makedir_p at src/shared/mkdir.c:134
#9 create_generator_dir at src/core/manager.c:2260
#11 manager_run_generators at src/core/manager.c:2316
#12 manager_reload at src/core/manager.c:2075
Created attachment 683021 [details]
Created attachment 683022 [details]
Created attachment 683023 [details]
Created attachment 683024 [details]
Created attachment 683025 [details]
Created attachment 683026 [details]
Created attachment 683027 [details]
Created attachment 683028 [details]
Created attachment 683029 [details]
Created attachment 683030 [details]
The crash happened when trying to lookup the SELinux label for "/run/systemd/generator", inside the pcre library (which is used by libselinux).
Is the crash reproducible? What is the version of selinux-policy? Have you added any custom SELinux file context mappings?
*** Bug 902354 has been marked as a duplicate of this bug. ***
I found an older abrt report where with a similar top of the stack:
I don't think this is systemd's bug. I'm reassigning this to one level below systemd, i.e. libselinux.
Is there a reliable reproducer here?
It (bz#902354) actually happens not the first time but often (if not every time) after selinux update, on different machines, though, but I haven't filed a bug report on it before this occurrence.
When it happens I'm not even able to reboot, neither remotely nor locally, so that I have to press reset key. I'm not able to stop/start/restart services. The reason is one: cannot send messages to systemd. This is a very big regression and instability factor.
(In reply to comment #15)
> It (bz#902354) actually happens not the first time but often (if not every
> time) after selinux update
What exactly do you mean by selinux update? An update of a SELinux-related package? Which one?
In bug 902354 you wrote:
> Description of problem:
> Change SELinux boolean
> setsebool -P httpd_can_network_connect_cobbler=on
Is this command what you mean by selinux update?
Did the crash happen immediately afterwards? Or was some other action needed?
Please be more exact in describing the steps that lead to the crash.
(In reply to comment #16)
> I have to press reset key.
A tip for you: "sync && reboot -f" is a little bit safer than hard reset button.
A policy update will cause systemd to reread the SELinux policy files. I guess this could be causing the problem.
Should be able to trigger this.
(In reply to comment #17)
> (In reply to comment #15)
> > It (bz#902354) actually happens not the first time but often (if not every
> > time) after selinux update
> What exactly do you mean by selinux update? An update of a SELinux-related
> package? Which one?
> In bug 902354 you wrote:
> > Description of problem:
> > Change SELinux boolean
> > setsebool -P httpd_can_network_connect_cobbler=on
> Is this command what you mean by selinux update?
> Did the crash happen immediately afterwards? Or was some other action needed?
> Please be more exact in describing the steps that lead to the crash.
> (In reply to comment #16)
> > I have to press reset key.
> A tip for you: "sync && reboot -f" is a little bit safer than hard reset
Sorry, I haven't look carefully your reply, while I have seen that there where some replies.
Thank you for a tip about more safe reboot.
As I remeber, the systemd bug have been occuring after sepol related packages update and after setsebool executing also. It seemes that it happend immediately afterwards, anyway after those actions immediately (setsebool) or after some time something happened that I could not reboot with systemd nor could I control services with it.
Dan, I tried your suggestion of load_policy, comment 18, on the system where we have experienced this issue twice. It did not trigger the issue though. We think the last event was triggered by doing a setsebool -P rsync_full_access off after doing an update to selinux-policy-3.11.1-82.fc18.noarch.
I have added a fix to libselinux-2.1.12-7.2.fc18 which will cause the creation of the .bin file to be atomic, which could be a cause of this error. Basically if an app tried to read the file while i was being written.
libselinux-2.1.12-7.2.fc18 has been submitted as an update for Fedora 18.
I see. As a test I ran this in one terminal:
while matchpathcon /run/systemd/generator > /dev/null; do :; done
and repeatedly tried this in another:
With the original libselinux it was easy to make matchpathcon crash. With the new one it didn't crash.
I also verified that "setsebool -P ..." somehow triggers the recompilation of file_contexts.bin.
It is reasonable to expect this bug is indeed fixed by the new libselinux.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libselinux-2.1.12-7.2.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libselinux-2.1.12-7.2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.