[systemd-devel] [PATCH] daemon-reload timestamped: coalesce redundant daemon-reloads

[Lennart Poettering]

On Tue, 02.12.14 13:19, Ken Sedgwick (ksedgwic at bonsai.com) wrote:

> Systems with many units (~10K) take many seconds to perform a
> daemon-reload.  The process of load-balancing these systems requires
> multiple daemon-reloads, many issued concurrently.  Currently many of
> these redundant daemon-reloads timeout and fail.
> 
> This patch adds a new systemd method ReloadTimestamped which contains
> the monotonic timestamp of the daemon-reload issuance.  When a
> ReloadTimestamped message is handled it's timestamp is compared to
> the timestamp of the most recent successful daemon reload.  If the
> message is redundant it is returns with success immediately.
> 
> The original Reload method is preserved to support compatibility with
> older systemctl versions.
> 
> If a new systemctl receives a SD_BUS_ERROR_UNKNOWN_METHOD error in
> response to ReloadTimestamped it retries with the original Reload
> method.

I am quite sympathetic to the idea of this, but there's something that
makes me feel uneasy about it:

On kdbus the sender timestamp can be implicitly attached to incoming
messages. This means that on kdbus systems we could implement this
without adding a new bus call, just by relying on the implicit sender
timestamp instead. Thus, if we'd apply your change like it is now,
then this would be made redundant as soon as we switch to kdbus, which
hopefully is within the next half year or so.

Not sure what to do about this. I wished we could attach the sender
timestamp in a nice way on dbus1 too, without having to actually send
it along as message payload. i.e. a header extension on dbus1 or so,
that is routed along by the daemon (maybe with some minimal validity
verification in dbus-daemon, so that the client cannot fake a sender
timestamp that is in the far future).

Hmm, anyone has ideas for this?

Lennart

-- 
Lennart Poettering, Red Hat