stop dbus-daemon memory usage ballooning if a client is slow to read
Submitted by Simon McVittie
Assigned to D-Bus Maintainers
Description
In the thread starting here http://lists.freedesktop.org/archives/dbus/2010-September/013575.html, and continued in October http://lists.freedesktop.org/archives/dbus/2010-October/013584.html, Alban Crequy wrote:
What happens when a process does not read its incoming D-Bus messages on the socket and other D-Bus peers keep sending messages to it?
With the default configuration on the session bus, dbus-daemon's memory usage is growing and the limit is really high:
<limit name="max_incoming_bytes">1000000000</limit><limit name="max_outgoing_bytes">1000000000</limit>
Later in the thread, Colin and Havoc wrote: http://lists.freedesktop.org/archives/dbus/2010-October/013621.html
Well, one thing we have discovered is that the current semantics of the bus daemon are pretty unfortunate, specifically the random arbitrary limits (127MiB and 1GB respectively for the system and session bus).
It would be within the spec, if the spec existed, to set these limits to infinite, if that's what you're suggesting. Another approach, I think you could make the sender do the buffering without changing any semantic. [*] Right now the daemon reads a message, decides it can't buffer it, and generates an error. Instead the daemon could read a message header, decide it can't buffer a message of that size, and then just stop reading from the socket until it can buffer it. Now the sender buffers messages and no messages ever fail to send. The exception would be if the single message is itself too large and can never succeed, then the daemon could generate an error.
Those are probably both better than sending the error, since the error isn't easily recoverable.
The approach I've marked [*] above sounds reasonable to me; this means that if a sender is particularly spammy, it's that sender that suffers (by being made to buffer messages). At the moment it's dbus-daemon that suffers, by consuming the messages as fast as possible, not being able to get rid of them fast enough and ballooning in size.
Turning this into a bug so it stays "on the radar" over time.
Version: 1.5