Discussion:
sd-bus: ObjectManager difference with gdbus
(too old to reply)
David Härdeman
2017-04-20 10:06:03 UTC
Permalink
Hi,

I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.

I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.

Under sd-bus, if an object is removed, the following signal is
generated:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]

If I implement the same simple server in gdbus, the signal is instead:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]

The corresponding signals are also generated when an object is added.

Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).

This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).

Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).

Regards,
David
David Herrmann
2017-04-20 12:19:22 UTC
Permalink
Hey
Post by David Härdeman
Hi,
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).
This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)

Thanks
David


diff --git a/src/libsystemd/sd-bus/bus-objects.c
b/src/libsystemd/sd-bus/bus-objects.c
index 9bd07ffca..b6f5afe1b 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
if (r < 0)
return r;

+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Peer", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Introspectable", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Properties", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.ObjectManager", 0);
+ if (r < 0)
+ return r;
+
found_something = true;
}
David Härdeman
2017-04-21 09:50:01 UTC
Permalink
Post by David Herrmann
Post by David Härdeman
Hi,
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).
This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
Post by David Herrmann
diff --git a/src/libsystemd/sd-bus/bus-objects.c
b/src/libsystemd/sd-bus/bus-objects.c
index 9bd07ffca..b6f5afe1b 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
if (r < 0)
return r;
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Peer", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Introspectable", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Properties", 0);
+ if (r < 0)
+ return r;
+
+ r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.ObjectManager", 0);
+ if (r < 0)
+ return r;
+
found_something = true;
}
--
David Härdeman
David Herrmann
2017-04-21 11:22:15 UTC
Permalink
Hi
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
Hi,
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).
This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.

Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.

Thanks
David
Lennart Poettering
2017-04-24 14:50:55 UTC
Permalink
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.
Yeah, I#d agree with that. I think we should provide complete
information, and that means including built-in interfaces in all our
messages, in particular as some of them are optional. It appears to
me, that gdbus should be changed here, not sd-bus...

Lennart
--
Lennart Poettering, Red Hat
Dan Williams
2017-04-24 15:49:35 UTC
Permalink
Post by Lennart Poettering
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
Anyway, gdbus bugs aside, it seems that the interfaces
reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Note that we really better report all interfaces an object
supports. I
don't know why glib does not do this, but I think it should.
Yeah, I#d agree with that. I think we should provide complete
information, and that means including built-in interfaces in all our
messages, in particular as some of them are optional. It appears to
me, that gdbus should be changed here, not sd-bus...
It's not clear that the GNOME side was implemented correctly yet.
Would be nice to see the sample code.

Dan
David Härdeman
2017-04-25 07:45:29 UTC
Permalink
Post by Dan Williams
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
Anyway, gdbus bugs aside, it seems that the interfaces
reported by
sd-bus should match what gdbus does? (assuming, of course,
that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Note that we really better report all interfaces an object
supports. I
don't know why glib does not do this, but I think it should.
Yeah, I#d agree with that. I think we should provide complete
information, and that means including built-in interfaces in all our
messages, in particular as some of them are optional. It appears to
me, that gdbus should be changed here, not sd-bus...
It's not clear that the GNOME side was implemented correctly yet.
Would be nice to see the sample code.
Dan
My GNOME-based client was based on the gdbus-example-objectmanager-client.c so I hope it's correct, but sure, I'll try to pare down the GNOME/gdbus-based client code and the (sd-bus based) server code to two simple test cases and provide those later this week.

Regards,
David
Dan Williams
2017-04-25 14:47:24 UTC
Permalink
Post by David Härdeman
Post by Dan Williams
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it
seems
to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Note that we really better report all interfaces an object
supports. I
don't know why glib does not do this, but I think it should.
Yeah, I#d agree with that. I think we should provide complete
information, and that means including built-in interfaces in all our
messages, in particular as some of them are optional. It appears to
me, that gdbus should be changed here, not sd-bus...
It's not clear that the GNOME side was implemented correctly yet.
Would be nice to see the sample code.
Dan
My GNOME-based client was based on the gdbus-example-objectmanager-
client.c so I hope it's correct, but sure, I'll try to pare down the
GNOME/gdbus-based client code and the (sd-bus based) server code to
two simple test cases and provide those later this week.
Cool. I'd be happy to take a look at it. It may well turn out to be a
gdbus bug, but without seeing the code it's not clear.

Dan
David Härdeman
2017-04-25 22:08:22 UTC
Permalink
Post by Dan Williams
Post by David Härdeman
Post by Dan Williams
It's not clear that the GNOME side was implemented correctly yet.
Would be nice to see the sample code.
Dan
My GNOME-based client was based on the gdbus-example-objectmanager-
client.c so I hope it's correct, but sure, I'll try to pare down the
GNOME/gdbus-based client code and the (sd-bus based) server code to
two simple test cases and provide those later this week.
Cool. I'd be happy to take a look at it. It may well turn out to be a
gdbus bug, but without seeing the code it's not clear.
I've added test cases at:
https://github.com/Alphix/gdbus-sdbus-test
--
David Härdeman
David Härdeman
2017-04-25 07:42:24 UTC
Permalink
Post by Lennart Poettering
Post by David Härdeman
Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.
Yeah, I#d agree with that. I think we should provide complete
information, and that means including built-in interfaces in all our
messages, in particular as some of them are optional. It appears to
me, that gdbus should be changed here, not sd-bus...
In that case, no changes are necessary to sd-bus since it already exposes all interfaces.

I've filed a bug report against gdbus:
https://bugzilla.gnome.org/show_bug.cgi?id=781524

Regards,
David
David Härdeman
2017-04-25 07:40:17 UTC
Permalink
Post by David Herrmann
Post by David Härdeman
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
....
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus that already *does* report all interfaces while gdbus doesnt?
Post by David Herrmann
Note that we really better report all interfaces an object supports. I
don't know why glib does not do this, but I think it should.
Maybe, I'm no dbus expert. And there does seem to be a bug in gdbus as well since the additional interfaces manage to confuse it. Anyway, it seems that either sd-bus should adapt the gdbus style or vice versa...maybe you could talk directly to the gdbus people?

Regards,
David
David Herrmann
2017-04-25 07:54:45 UTC
Permalink
Hi
Post by David Härdeman
Post by David Herrmann
Post by David Härdeman
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
....
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus that already *does* report all interfaces while gdbus doesnt?
No, it does not. sd-bus was inconsistent. See, there are 3 things
involved in the Object-Manager:

Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects

The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.

So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).

Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.

I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.

Thanks
David
Lennart Poettering
2017-04-25 08:05:38 UTC
Permalink
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus that already *does* report all interfaces while gdbus doesnt?
No, it does not. sd-bus was inconsistent. See, there are 3 things
Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects
The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.
So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).
Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.
I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.
Could you please send the sd-bus side fix as PR?

Lennart
--
Lennart Poettering, Red Hat
David Herrmann
2017-04-25 08:27:02 UTC
Permalink
Hey

On Tue, Apr 25, 2017 at 10:05 AM, Lennart Poettering
Post by Lennart Poettering
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus that already *does* report all interfaces while gdbus doesnt?
No, it does not. sd-bus was inconsistent. See, there are 3 things
Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects
The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.
So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).
Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.
I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.
Could you please send the sd-bus side fix as PR?
Now pending as #5799.

Thanks
David
David Härdeman
2017-04-25 19:21:19 UTC
Permalink
Post by David Herrmann
Post by David Härdeman
Post by David Herrmann
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus that already *does* report all interfaces while gdbus doesnt?
No, it does not. sd-bus was inconsistent. See, there are 3 things
Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects
The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.
So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).
Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.
I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.
Ok, I've tried the patch. It seems to fix things insofar that
InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
interfaces (checked with dbus-monitor).

gdbus still gets royally confused though. It seems to report 5
interfaces for objects which are added dynamically (i.e. signalled via
InterfacesAdded) and 1 interface for objects which are generated via
GetManagedObjects (even though the sd-bus server reports 5 interfaces).

I'll start working on a testcase...
--
David Härdeman
David Härdeman
2017-04-25 22:10:42 UTC
Permalink
Post by David Härdeman
Post by David Herrmann
No, it does not. sd-bus was inconsistent. See, there are 3 things
Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects
The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.
So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).
Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.
I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.
Ok, I've tried the patch. It seems to fix things insofar that
InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
interfaces (checked with dbus-monitor).
gdbus still gets royally confused though. It seems to report 5
interfaces for objects which are added dynamically (i.e. signalled via
InterfacesAdded) and 1 interface for objects which are generated via
GetManagedObjects (even though the sd-bus server reports 5 interfaces).
Scratch that. With your patch gdbus seems to consistently report 5
interfaces. But there's still some confusion to address in gdbus (the
additional interfaces have no names for example).
--
David Härdeman
David Härdeman
2017-04-25 07:59:34 UTC
Permalink
Post by David Herrmann
Hi
Post by David Härdeman
I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.
I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.
Under sd-bus, if an object is removed, the following signal is
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.freedesktop.DBus.Peer"
string "org.freedesktop.DBus.Introspectable"
string "org.freedesktop.DBus.Properties"
string "org.freedesktop.DBus.ObjectManager"
string "org.gnome.TestManager.Device"
]
signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
object path "/org/gnome/TestManager/foo0"
array [
string "org.gnome.TestManager.Device"
]
The corresponding signals are also generated when an object is added.
....
Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)
Haven't tried it yet, but just from reading the patch...it seems to do
the opposite of what I'd expect? I.e. add *more* interfaces?
Post by David Herrmann
This change makes sure all objects have the built-in interfaces
reported at all times. The GetManagedObjects() call didn't report them
so far.
Quite the contrary? If you look at the output from dbus-monitor above, you'll see that it is sd-bus
that already *does* report all interfaces while gdbus doesnt?
No, it does not. sd-bus was inconsistent. See, there are 3 things
Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects
The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.
So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).
Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.
Oh, I see. Thanks. I'll try the patch ASAP.

Regards,
David
Loading...