Bug 1286503
Summary: | systemd-logind (and other services) fail to start after a reboot | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kent Yoder <kentyoder> | ||||
Component: | systemd | Assignee: | systemd-maint | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 22 | CC: | johannbg, kdudka, lnykryn, msekleta, ovasik, s, systemd-maint, zbyszek | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-12-01 01:20:34 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: | |||||||
Attachments: |
|
systemd-logind is installed by the systemd package, not by the basesystem package, which is a meta-package only, thus installs no files at all. Does it work if you reboot and set 'setenforce=0' on the kernel command line? Thanks Kamil. Zbigniew: I haven't tried setenforce=0 on the kernel command line, only selinux=0, which didn't change anything. I have tried this: logging in using single user mode, then `telinit 3`, then `setenforce 0` on the command line. At that point I tried manually doing `systemctl start systemd-logind.service`, which failed, and the console logged the avc denied error I listed above (or at least looked very similiar, I'm not positive it was the exact same). This makes no sense to me. I'll rpm verify my selinux packages this evening to see if something's been corrupted. rpm -qa --verify showed that / was mode 0600. Set it to 0755 and everything returned to normal. systemd-logind starts, all other services start up ok. Closing. |
Created attachment 1100347 [details] audit log, audit2allow output, journalctl output, rpm-qa info, etc Description of problem: Multiple services fail to start including systemd-logind, preventing login except through single user mode. The specific systemd-logind messages are: Nov 29 21:33:28 localhost systemd-logind: Failed to add match for NameOwnerChanged: Connection reset by peer Nov 29 21:33:28 localhost systemd-logind: Failed to fully start up daemon: Connection reset by peer Nov 29 21:33:28 localhost systemd: systemd-logind.service: main process exited, code=exited, status=1/FAILURE Nov 29 21:33:28 localhost systemd: Failed to start Login Service. Nov 29 21:33:28 localhost systemd: Unit systemd-logind.service entered failed state. Nov 29 21:33:28 localhost systemd: systemd-logind.service failed. However, the common error between all failing services seems to be an selinux deny in talking to dbus. Version-Release number of selected component (if applicable): systemd-219-25.fc22.x86_64 systemd-python3-219-25.fc22.x86_64 systemd-libs-219-25.fc22.x86_64 systemd-python-219-25.fc22.x86_64 systemd-compat-libs-219-25.fc22.x86_64 How reproducible: always Steps to Reproduce: 1. boot 2. systemd-logind, firewalld, others fail to start Additional info: Lots of selinux deny messages in the audit log such as this: type=USER_AVC msg=audit(1448852007.264:919): pid=703 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=1614 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus exe="?" sauid=81 hostname=? addr=? terminal=?' I assumed this was a relabeling issue, set /.autorelabel, rebooted, no change. Next, grepped the audit log and piped to audit2allow, but for every single rule it generated, it warned that the avc is allowed by current policy (see attachment). Next, rebooted with selinux=0, but no change. So now I'm thinking this has nothing to do with selinux.