Re: dbus Digest, Vol 206, Issue 1

Help: unsubscribe 

Sent from my iPhone

> On Mar 3, 2023, at 6:00 AM, [email protected] wrote:
> 
> Send dbus mailing list submissions to
>    [email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.freedesktop.org/mailman/listinfo/dbus
> or, via email, send a message with subject or body 'help' to
>    [email protected]
> 
> You can reach the person managing the list at
>    [email protected]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dbus digest..."
> 
> 
> Today's Topics:
> 
>   1. method timeouts vs systemd activation and slow systems
>      (Colin Walters)
>   2. Re: method timeouts vs systemd activation and slow systems
>      (Lawrence D'Oliveiro)
>   3. Re: method timeouts vs systemd activation and slow systems
>      (Thiago Macieira)
>   4. Re: method timeouts vs systemd activation and slow systems
>      (Thiago Macieira)
>   5. Re: method timeouts vs systemd activation and slow systems
>      (Lawrence D'Oliveiro)
>   6. Re: method timeouts vs systemd activation and slow systems
>      (Lennart Poettering)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 02 Mar 2023 10:15:23 -0500
> From: "Colin Walters" <[email protected]>
> To: [email protected]
> Subject: method timeouts vs systemd activation and slow systems
> Message-ID: <[email protected]>
> Content-Type: text/plain
> 
> A while ago now my role switched from working on the Linux desktop to working on Linux servers, and since then I've discovered that servers are a bit more of a wild world.  
> 
> Long ago I think Havoc chose to default to 25 second timeouts for DBus method calls.  This is generally OK on mostly idle single-user desktop systems.  (Particularly modern laptops/desktops with NVMe drives etc.)
> 
> But servers...well, it turns out that some people want to e.g. use under-resourced (or rather over-provisioned) private OpenStack instances for example - and there, I/O can be *really* slow.  And basically we start seeing the 25 second DBus method call show up here as system failures.
> 
> Now later, systemd came along and started defaulting to 90 seconds for service activation.  This is IMO a bit more reasonable of a timeout.
> 
> But crucially - the systemd activation timeout can be conveniently configured *system wide*.  And basically that's what I want here - the ability to change the OS to detect this situation and globally affect dbus method call timeouts.
> 
> Now unfortunately today, these timeouts are hardcoded in client code.  But...here's my strawman:
> 
> - Change dbus-{daemon,broker} to have a config for this
> - Default that config to the systemd service start timeout
> - Fix client libraries to query the daemon for the timeout (or parse the configs on their own? not sure)
> 
> Also xref the related https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer and my comment https://github.com/coreos/fedora-coreos-tracker/issues/1404#issuecomment-1412827914
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 3 Mar 2023 10:21:25 +1300
> From: Lawrence D'Oliveiro <[email protected]>
> To: [email protected]
> Subject: Re: method timeouts vs systemd activation and slow systems
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII
> 
>> On Thu, 02 Mar 2023 10:15:23 -0500, Colin Walters wrote:
>> 
>> - Fix client libraries to query the daemon for the timeout (or parse
>> the configs on their own? not sure)
> 
> An environment variable would seem to be the natural way to specify
> this.
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 02 Mar 2023 19:01:54 -0800
> From: Thiago Macieira <[email protected]>
> To: [email protected]
> Subject: Re: method timeouts vs systemd activation and slow systems
> Message-ID: <21226828.hcdKbhU8Es@tjmaciei-mobl5>
> Content-Type: text/plain; charset="us-ascii"
> 
>> On Thursday, 2 March 2023 13:21:25 PST Lawrence D'Oliveiro wrote:
>>> On Thu, 02 Mar 2023 10:15:23 -0500, Colin Walters wrote:
>>> - Fix client libraries to query the daemon for the timeout (or parse
>>> the configs on their own? not sure)
>> 
>> An environment variable would seem to be the natural way to specify
>> this.
> 
> Would be far easier to parse, indeed. Querying the daemon after start would be 
> second best, because it would avoid having to parse a config file.
> 
> However, environments do sometimes get cleared, so a child process somewhere 
> down the tree could lose it. Obviously that can't happen for a session daemon, 
> because they'd have lost the bus address too, but Colin is talking about 
> servers, so sessions may not be anywhere in sight. A query to the daemon would 
> apply to all processes that, well, talk to the daemon :)
> 
> Is there a security concern here for environment variables?
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Software Architect - Intel DCAI Cloud Engineering
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 02 Mar 2023 19:04:05 -0800
> From: Thiago Macieira <[email protected]>
> To: [email protected]
> Subject: Re: method timeouts vs systemd activation and slow systems
> Message-ID: <2458919.NeW584JBU5@tjmaciei-mobl5>
> Content-Type: text/plain; charset="us-ascii"
> 
>> On Thursday, 2 March 2023 07:15:23 PST Colin Walters wrote:
>> A while ago now my role switched from working on the Linux desktop to
>> working on Linux servers, and since then I've discovered that servers are a
>> bit more of a wild world.
> 
> Welcome to the club.
> 
> We spend a lot of time making the base runtime as fast as possible so the 
> higher layers write everything in interpreted languages and have shell scripts 
> doing "sleep 1s; poll something".
> 
> Well, every cycle saved counts.
> 
> -- 
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>   Software Architect - Intel DCAI Cloud Engineering
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 3 Mar 2023 16:18:21 +1300
> From: Lawrence D'Oliveiro <[email protected]>
> To: [email protected]
> Subject: Re: method timeouts vs systemd activation and slow systems
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8
> 
>> On Thu, 02 Mar 2023 19:04:05 -0800, Thiago Macieira wrote:
>> 
>> ... and have shell scripts doing "sleep 1s; poll something".
> 
> What?s the bet the next version of bash will have a builtin command for
> poll(2) ...
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 3 Mar 2023 09:45:52 +0100
> From: Lennart Poettering <[email protected]>
> To: Colin Walters <[email protected]>
> Cc: [email protected]
> Subject: Re: method timeouts vs systemd activation and slow systems
> Message-ID: <ZAGzwGcpIY01BSUt@gardel-login>
> Content-Type: text/plain; charset=utf-8
> 
> eOn Do, 02.03.23 10:15, Colin Walters ([email protected]) wrote:
> 
>> - Fix client libraries to query the daemon for the timeout (or parse
>>  the configs on their own? not sure)
> 
> That kinda creates a conceptual cyclic dep, no? to query the default
> timeout you issue a method call, thus you need to query the default
> timeout, which you issue a method call for, thus you need to query the
> default timeout, which you isue a method call for, thus you ne?
> 
> This isn't hard to break of course, but suggests to me that maybe this
> is a parameter that should be agreed on before the usual dbus message
> chatter begins, i.e. maybe as part of the auth protocol? similar to
> the agreement on the unix-fd support, maybe client and server could
> exchange other parameters, such as he default method call timeout.
> 
> This also has the benefit thta it is easier to pipeline, as full
> roundtrips are nasty nasty business.
> 
> That all said, I don't see anyone volunteering to do the work to
> extend the protocol for this. Or are you volunteering?
> 
> I see your problem though, and it is kinda broken that the activation
> timeout is longer than the method call timeout. Hence I am kinda
> tempted to just bump the default method call timeout in
> sd-bus. That'll fix a lot of low-level software, but of course not
> stuff relying on libdbus or glib's logic.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> dbus mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/dbus
> 
> 
> ------------------------------
> 
> End of dbus Digest, Vol 206, Issue 1
> ************************************