Created attachment 600040 [details] console log from boot Opening as a systemd bug, but may be some other component that's broken... Recently, when I reboot my rawhide machine, it drops to an emergency mode prompt due to what looks like dependency issues. It also looks like systemd is constantly starting and stopping the journald service. Not sure if that's expected or not...
Oh, if I subsequently hit ^d at the prompt, then it seems to boot just fine. Also, this may be of interest: [root@rawhide ~]# systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: inactive (dead) (Result: exit-code) since Tue, 24 Jul 2012 10:21:57 -0400; 11s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Process: 363 ExecStart=/usr/lib/systemd/systemd-journald (code=exited, status=1/FAILURE) Status: "Shutting down..." CGroup: name=systemd:/system/systemd-journald.service
A failing journal service is definitely interesting. > systemd-journald[294]: Unknown socket passed. Would you paste also the output of "systemctl status systemd-journald.socket"?
From emergency mode: [root@rawhide ~]# systemctl status systemd-journald.socket systemd-journald.socket - Journal Socket Loaded: loaded (/usr/lib/systemd/system/systemd-journald.socket; static) Active: failed (Result: service-failed-permanent) since Tue, 24 Jul 2012 12:02:46 -0400; 22s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) CGroup: name=systemd:/system/systemd-journald.socket The interesting bit is if I exit emergency mode and let it boot up the rest of the way, it seems to be fine: [root@rawhide ~]# systemctl status systemd-journald.socket systemd-journald.socket - Journal Socket Loaded: loaded (/usr/lib/systemd/system/systemd-journald.socket; static) Active: active (running) since Tue, 24 Jul 2012 12:03:33 -0400; 12s ago Docs: man:systemd-journald.service(8) man:journald.conf(5) CGroup: name=systemd:/system/systemd-journald.socket ...sort of smells like a race of some sort, but I don't know enough about the design of the journald stuff to say for sure.
Are there SELinux denials? Try booting with enforcing=0.
Good call. Machine boots fine with enforcing=0. I tried doing a full relabel (by touching /.autorelabel and rebooting) but it didn't help. Should we move this to an selinux-policy bug?
It depends. Please paste the AVC denial messages you're getting (in dmesg or audit.log).
Booting with selinux set to enforcing, I don't see any avc messages (which seems odd), but if I boot with it in permissive mode I see these: [ 2.140434] type=1400 audit(1343212438.114:3): avc: denied { getattr } for pid=269 comm="systemd-journal" path="socket:[5497]" dev="sockfs" ino=5497 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket [ 2.140446] type=1400 audit(1343212438.114:4): avc: denied { getattr } for pid=269 comm="systemd-journal" path="socket:[5500]" dev="sockfs" ino=5500 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket [ 3.485759] type=1400 audit(1343212439.459:5): avc: denied { write } for pid=269 comm="systemd-journal" name="journal" dev="tmpfs" ino=5498 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir [ 3.485765] type=1400 audit(1343212439.459:6): avc: denied { add_name } for pid=269 comm="systemd-journal" name="flushed" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir [ 3.485805] type=1400 audit(1343212439.459:7): avc: denied { create } for pid=269 comm="systemd-journal" name="flushed" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file [ 3.485836] type=1400 audit(1343212439.459:8): avc: denied { write open } for pid=269 comm="systemd-journal" path="/run/systemd/journal/flushed" dev="tmpfs" ino=10660 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
The journal socket is labeled kernel_t because it is created in the initramfs while the SELinux policy is not yet loaded. The open socket is then intentionally "leaked" to the main systemd when switching to the real root filesystem. We need a way to relabel active sockets after loading the policy. And we don't even know yet if the kernel allows it. (As discussed on IRC yesterday.)
Fixed in selinux-policy-3.11.0-15.fc18.noarch