Bug 907576
| Summary: | error trying to start rtkit-daemon.service | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Garrett Mitchener <garrett.mitchener> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bruno, gansalmon, itamar, johannbg, jonathan, kernel-maint, lnykryn, lpoetter, madhu.chinakonda, metherid, mschmidt, msekleta, notting, plautrba, schaiba, systemd-maint, vpavlin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-06 16:49:42 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: | |||
|
Description
Garrett Mitchener
2013-02-04 18:27:57 UTC
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. |