[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: method timeouts vs systemd activation and slow systems
From:       "Colin Walters" <walters () verbum ! org>
Date:       2023-03-17 14:09:50
Message-ID: 9c99cf0e-546f-4020-8b09-1b5b6be7face () betaapp ! fastmail ! com
[Download RAW message or body]



On Wed, Mar 8, 2023, at 3:04 AM, David Rheinsberg wrote:
> Hi
> 
> On Mon, Mar 6, 2023, at 1:39 PM, Simon McVittie wrote:
> > There are some timeouts in the "limits" data structure of the message
> > bus implementation (dbus-daemon or dbus-broker) which are somewhat
> > orthogonal to the client-side method call timeout. In dbus-daemon
> > configuration language:
> > 
> > * service_start_timeout (default 25s)
> > * auth_timeout (default 5s)
> > * pending_fd_timeout (default 150s)
> 
> For the record, we do not use those timeouts in dbus-broker. 
> "Service-start" is under control of systemd, and for the other two we 
> do not implement the timeouts since we have resource accounting in both 
> situations (which requires rather recent linux APIs and does not 
> necessarily have an equivalent on other platforms).
> 
> 
> Regarding the proposal: I can only recommend dropping timeouts in dbus 
> transactions.

Yeah, fair.  I agree overall with the long term direction.  The risk here though is \
that anyone doing *synchronous* dbus calls from a mainloop now need to kill the app \
and restart if the target service fails to respond.

For system components (e.g. system daemons or gnome-shell type things) I would really \
hope for example there aren't any synchronous calls.  But if there are, then the UX \
for a desktop user is they may need to power cycle.

> Lastly, note that whenever you "timeout" a method-transaction in a 
> dbus-client, you leak the reply-window in the server. Unless the other 
> side eventually replies or disconnects, you will accumulate those 
> reply-windows and eventually reach your resource limit.

Ah, ouch.


[prev in list] [next in list] [prev in thread] [next in thread]