Bug 842758

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