Description of problem: I can't get rtkit-daemon to start properly. The command systemctl start rtkit-daemon.service fails, says ExecStart=/usr/libexec/rtkit-daemon (code=exited, status=225/NETWORK) The info from journalctl -xn says Failed at step NETWORK spawning /usr/libexec/rtkit-daemon: Invalid argument but I can manually run /usr/libexec/rtkit-daemon from a command line as root. Once I do that, gdm and gnome seem to start more or less normally. I'm marking this as high severity because until I do that manual start, gdm comes up completely black and blank, no login window, nothing. This is with rtkit-0.11-3.fc19.i686 running on a virtual machine where I installed F18 and updated it to rawhide with yum. Possibly related: bug #835848 bug #901926 (For whatever reason, /var/tmp is a symlink to /tmp on this machine)
I am seeing this in rawhide and f18 on i686 when using recent 3.8 kernels. Older 3.8 kernels work OK. I also don't see this on x86_64. (Over 3 machines. 1 i686 rawhide, 1 i686 f18 with rawhide kernels, 1 x86_64 f18 with rawhide kernels) The last working kernel is 3.8.0-0.rc5.git1.1.fc19.i686.PAE. Note that gdm and normal sessions will eventually timeout waiting for rtkit and then things seem to work more or less normally without having to start it.
I'm impatient :-) I tracked part of the problem to /lib/systemd/system/rtkit-daemon.service I commented out the private network line: #PrivateNetwork=yes and got it to work. Whatever that PrivateNetwork is, it's not in f17, and apparently it doesn't work right now.
I can confirm that turning off the private network feature works around the problem.
I heard back from the kernel guys and namespaces aren't turned on for i686. My guess is that an error status code might be different now than before and systemd is handling this case differently than how it handled things in the previous state. I think this bug should get moved to systemd, since it doesn't appear to be directly a rtkit bug. If you disagree you can switch it back, but for now I have moved it.
CONFIG_NAMESPACES=y and CONFIG_NET_NS=y were enabled even on i686 before. So perhaps this commit disabled namespaces on i686 by mistake?: commit ebd1a1737a5296bef20ee5706a5937a2275798d1 Author: Josh Boyer <jwboyer> Date: Wed Jan 30 10:55:31 2013 -0500 Linux v3.8-rc5-218-ga56e160 - Enable NAMESPACES and CHECKPOINT_RESTORE on x86_64 for F19 CRIU feature - Enable CONFIG_DEBUG_ATOMIC_SLEEP
Oh. How bizarre. So the Kconfig entry for NAMESPACES looks like: menuconfig NAMESPACES bool "Namespaces support" if EXPERT default !EXPERT help Originally, it wasn't a menuconfig but just a plain config option. The intention was to only allow it to be enabled if CONFIG_EMBEDDED was enabled (renamed to CONFIG_EXPERT). We've never had either of those options set, so NAMESPACES wasn't explicitly set in our config files. We did, however, have NET_NS and a couple others enabled forever, so apparently it was getting turned on anyway. Fun! I'll rework the commit for the CRIU feature so NAMESPACES comes back on for 32-bit.
OK, so I've enabled it again. Should be in tomorrow's rawhide kernels. However, it seems pretty fragile for rtkit-daemon to just fail if a kernel config option is disabled. You might want to actually code it so it looks to see if the feature is present instead of blindly assuming it's set.
I tested 3.8.0-0.rc6.git3.3.fc19.i686.PAE and it does appear to fix things. Thanks.