Mark SetBrightness D-Bus calls as no-reply to prevent a reply leak that exhausts the user's bus quota

[d3vv3]

Summary

On the logind D-Bus brightness path (src/brightness/backlight.rs, used when wluma lacks direct write permission to the sysfs brightness file), wluma sends SetBrightness method calls on a dbus::blocking::Connection but never drains the connection — process() / read_write() are never called anywhere in the codebase.

A normal method call expects a reply, so logind returns a method_return for every SetBrightness. Nobody ever reads those replies, so they accumulate without bound in the bus daemon's outgoing queue toward wluma. Because dbus-broker accounts message memory per user, this slowly consumes the user's entire quota. Once it's exhausted, the bus daemon starts disconnecting that user's other clients whenever they request a sizable reply:

dbus-broker: Peer :1.NNNN is being disconnected as it does not have the
resources to receive a reply it requested.

In practice this manifests as unrelated tools breaking — e.g. nm-applet / nmcli reporting "NetworkManager is not running" even though it is, because libnm's GetManagedObjects() reply can no longer be received. Killing wluma (or here, fixing it) immediately frees the quota and the other clients recover. The backed-up socket is directly observable via ss -xp | grep system_bus_socket — wluma's connection shows a large, growing Send-Q.

Fix

SetBrightness has no meaningful return value, so flag the message as no-reply (Message::set_no_reply(true)). logind then never generates a reply and nothing accumulates. Minimal, and keeps the existing fire-and-forget send() model.

(An alternative would be to pump the connection with connection.process(Duration::ZERO) after each send, but suppressing the reply at the source is cleaner and cheaper.)

Testing

• cargo build succeeds against dbus 0.9.11 (confirms set_no_reply API usage).
• cargo fmt --check clean.
• The functional behavior of SetBrightness is unchanged; only the now-unused reply is suppressed.

[max-baz]

Thanks! It looks like the default value is already false ( if you follow the chain starting from https://docs.rs/dbus/latest/dbus/message/struct.Message.html#method.Set_no_reply ), do you have some evidence that this PR in fact is not a noop?

[d3vv3]

Hi @max-baz, the no_reply is false by default, meaning a reply is expected. We are changing it to true now, so a reply will not be expected. So it is not a no-op.

[max-baz]

Thanks, and apologies! My bad, I started going down the docs and confused myself in the negations 😅 I think the lints are unrelated to your changes, I'll address them later.