method timeouts vs systemd activation and slow systems

[Colin Walters]

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.