On Tue, 02.12.14 13:19, Ken Sedgwick (ksedg...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
