Description of problem: Shortly after login cockpitd loses the connection to the session dbus-daemon, with a message like this in the journal: Jul 22 16:49:26 jalisco.cube.lan cockpitd[9784]: Failed to acquire the name com.redhat.Cockpit on the session message bus Jul 22 16:49:26 jalisco.cube.lan cockpitd[9784]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Version-Release number of selected component (if applicable): cockpit-0.16-1.fc21.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install Fedora 21 Server 2. Log into Cockpit 3. List of servers on dashboard flickers, and disappears.
From mitr: (… and (setenforce 0) does show the post-login screen, and briefly a server icon in the list, but the server disappears immediately. Adding “localhost” as a server then doesn’t work.) https://bugzilla.redhat.com/show_bug.cgi?id=1121761#c2
Emitting the following DBus message from cockpitd causes it to get kicked off the session bus: /com/redhat/Cockpit/CpuMonitor com.redhat.Cockpit.ResourceMonitor NewSample (int64 1406043367553044, [0.0, 8.0, 22.0, 0.0])
dbus-1.8.6-2.fc21.x86_64
I'd guess this is an issue with GDBus serialization. I'm guessing not many projects use "ad".
Definitely broken, just try: gdbus emit -y -o /blah -s com.example.Blah.Blah '@au [0, 42, 43, 57]' ^ works gdbus emit -y -o /blah -s com.example.Blah.Blah '@ad [0.0, 42.42, 43.43, 57.9]' ^ fails
Maybe regression from https://bugzilla.gnome.org/show_bug.cgi?id=732754 ?
Created attachment 919962 [details] Test case for DBus regression Confirming that this is a dbus regression. The attached test case demonstrates this. Bad behavior (using dbus-daemon from dbus-1.8.6-2.fc21.x86_64 along with dbus-monitor): $ ./test-dbus-xad signal sender=org.freedesktop.DBus -> dest=(null destination) serial=25 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.10" string "" string ":1.10" method call sender=:1.10 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello sent: /path org.iface.Test.MySignal ([0.0, 8.0, 22.0, 0.0],) signal sender=org.freedesktop.DBus -> dest=(null destination) serial=26 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.10" string ":1.10" string "" g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. Terminated Correct behavior (using dbus-daemon from dbus-1.6.12-8.fc20.x86_64 along with dbus-monitor): $ ./test-dbus-xad signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.1" string "" string ":1.1" method call sender=:1.1 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=:1.1 -> dest=(null destination) serial=2 path=/path; interface=org.iface.Test; member=MySignal int64 1406043367553044 array [ double 0 sent: /path org.iface.Test.MySignal (int64 1406043367553044, [0.0, 8.0, 22.0, 0.0]) double 8 double 22 double 0 ] ^C
Yep, confirmed reverting those patches fixes it.
Hmm. I was testing with dbus-1.6.12-8.el7.x86_64 and glib2-2.40.0-1.el7.x86_64 (works). With glib2 from git, it fails. When reverting the glib array fast path bits, it works again. So the next thing to test is whether new dbus, but old glib works.
Yup you're right. glib regression Works with: glib2-2.40.0-1.fc21.x86_64 Fails with: glib2-2.41.2-1.fc21.x86_64
Worked on a patch upstream: https://bugzilla.gnome.org/show_bug.cgi?id=732754
Scratch build with the patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=7183810
Created attachment 920179 [details] Fedora glib2 build fix for the regression Here's a patch to the glib2 spec file and fedora build for f21 which fixes the issue.
Building for f21 and rawhide.
Upstream patch reviewed and pushed.
Discussed at 2014-07-23 Alpha blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-07-23/f21-blocker-review.2014-07-23-15.59.log.txt . Accepted as a blocker per criterion "Unless explicitly specified otherwise, after system installation the Cockpit web management interface must be running and accessible on its default port (XX).", https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Cockpit_management_interface .
F21 is not gated via bodhi yet, so the fixed build is already in 'stable' - http://koji.fedoraproject.org/koji/buildinfo?buildID=547263 . Can someone please re-test and confirm this is now fixed? thanks.
Upstream has a better patch. The update does fix the symptom (cockpit not starting). So VERIFIED unless Colin or Matthias wants to pick up the better patch. # rpm -q glib2 glib2-2.41.2-2.fc21.x86_64
as long as the bug'd fixed i'd say we're good. the 'better patch' can be picked up down the road without downstream tracking needed.