[PATCH] dbus-glib patches

David Zeuthen david at fubar.dk
Mon Mar 17 12:39:34 PDT 2008


On Mon, 2008-03-17 at 20:17 +0100, Rob Taylor wrote:
> David Zeuthen wrote:
> > On Mon, 2008-03-17 at 19:58 +0100, Rob Taylor wrote:
> >> I was more concerned about documenting that the bus daemon also has a 
> >> timeout for method calls, defaulting to 25 seconds, so no matter whet 
> >> you set in this function, if your method takes more than 25 seconds an 
> >> error will be returned to the caller.
> > 
> > No, the bus timeout is around six hours or so.
> 
> No, we're both wrong, its 5 minutes (bus/config_parser.c:434)

That is just busted. But thanks for letting me know, I'll patch the
package in Fedora to use INT_MAX and tell all users of my software that
they need to do the same.

On a more constructive note it's just not useful to set it to five
minutes. It's forcing application writers to use a specific pattern
(that increases complexities and possibly creates covert channels, see
my other mail) for no good reason. I don't think the reference
implementation of the D-Bus messaging system should impose such design
patterns on application writers.

> > (And if you couldn't do method calls of longer than 25 seconds D-Bus
> > would be completely useless for non-trivial applications.)
> > 
> > And it's still a complete mystery to me why the bus timeout is there;
> > FWIW, I consider it a bug that should be fixed along with treating
> > timeout==INT_MAX as special to avoid silly 49.52 earth day wrap around
> > issues (because 31 bits is all we use for millisecond timeout).
> 
> Agreed, I don't understand why the timeout is there.

Havoc? Can we change this?

> > (Btw, there's another bug in the bus daemon and/or libdbus; it uses wall
> > clock for accounting purposes meaning that time doesn't stand still
> > while the system is e.g. suspended or hibernated. On Linux you want to
> > use the 19th entry of /proc/$pid/stat to avoid this (or similar
> > constructs). Also, if the clock currently used by the bus daemon isn't
> > monotonically increasing some people may call this a security bug too.)
> 
> +1
> 
> Thanks,
> Rob
> 
> >      David
> > 
> > 
> > _______________________________________________
> > dbus mailing list
> > dbus at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dbus
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus



More information about the dbus mailing list