Bug 1122128

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.