dvdhrm
commented
5 years ago Thanks a lot for the report! I have some more questions, though:
Distro is Arch Linux.
dbus-broker version is 20, and is from the offical repo.
Usually, it's very slow and steady.
What do you mean with it is very slow and steady? I am not sure what to make of this. Can you elaborate?
A couple of instances, I've left my machine overnight, come back, and I've only noticed when I try starting Steam, with it crashing due to a DBus error I can't recall, and then seeing that dbus-broker was consuming many GiB of RAM.
I'll try and grab screenshots next time, if necessary.
I did grab the log from
journalctl, however:Halfway, the log suffers ridiculous spamming which is probably what resulted in the event of dbus-broker consuming GiBs of RAM.
Current dbus-broker RAM usage is 43KiB. Was certainly a lot smaller earlier today.
Yeah, the logs are quite expressive. First of all, since dbus-broker-20, the log-spam with the following message is now suppressed:
`dbus-broker-launch[590]: Activation request for 'org.freedesktop.resolve1' failed: Unit dbus-org.freedesktop.resolve1.service not found.`So the first 13k lines of that log can be ignored.
Starting at line 13165 you have a reboot where the excessive memory consumption happens. The relevant log-messages are:
dbus-broker[573]: UID 1000 exceeded its 'bytes' quota on UID 1000.
dbus-broker[573]: Peer :1.95 is being disconnected as it does not have the resources to receive a signal it subscribed to.
dbus-broker[573]: Peer :1.166367 is being disconnected as it does not have the resources to receive a reply or unicast signal it expects.
dbus-broker[573]: Peer :1.43 is being disconnected as it does not have the resources to receive a signal it subscribed to.
dbus-broker[573]: Peer :1.166391 is being disconnected as it does not have the resources to receive a reply or unicast signal it expects.
dbus-broker[573]: Peer :1.166392 is being disconnected as it does not have the resources to receive a reply or unicast signal it expects....and this then continues with many more messages just like the last one.
What is going on here is that your UID (which I assume is 1000) exceeded its memory quota on the system bus. The D-Bus message bus allows all users on your system to send messages, and as long as a message was not yet received/dequeued by its receiver, it must be buffered somewhere. In the case of D-Bus the messages must be buffered in the message bus instance. To make sure a single UID on the system cannot exploit the entire system message bus, the allowed number of messages (more precisely: the number of bytes) is limited per user. Furthermore, there are quotas applied if a message is sent from one UID to a different UID, to protect the UIDs from each other.
The first log-message in that log-excerpt tells you that the user with UID 1000 has so many pending messages (or other D-Bus objects) that it exceeded its own allowance. Hence, further attempts by that user to send more messages are rejected.
Of course, I cannot tell for sure, but my assumption based on these log-messages is that dbus-broker does exactly what it is told: It tries to transmit the messages it is given by the clients. The problem is, there seems to be some client on your system that runs under your UID which either does not dequeue its messages, or exhibits some other buggy client-behavior.
In my opinion, there is little dbus-broker can do here. The memory-limits dbus-broker has for clients is configurable, so you can reduce it if you want dbus-broker to reduce the memory consumption (Note that these limits are defined by the dbus-daemon project, and dbus-broker has a compatibility layer to parse them). However, this will not fix your bug, since there will still be a buggy client application that consumes all resources of your UID. What dbus-broker definitely should do, though, is to print more elaborate diagnostics and some heuristics to try to find the buggy client.
Anyway, maybe you have a suspicion about which application triggers this behavior? In this case it should be a lot easier to track down.
Thanks David
Valmar33
hit0ri
teg
brianjmurrell
braveheuel
vosian
AdamWill
Distro is Arch Linux.
dbus-broker version is 20, and is from the offical repo.
Usually, it's very slow and steady.
A couple of instances, I've left my machine overnight, come back, and I've only noticed when I try starting Steam, with it crashing due to a DBus error I can't recall, and then seeing that dbus-broker was consuming many GiB of RAM.
I'll try and grab screenshots next time, if necessary.
I did grab the log from
journalctl, however:dbus-broker.tar.gz
Halfway, the log suffers ridiculous spamming which is probably what resulted in the event of dbus-broker consuming GiBs of RAM.
Current dbus-broker RAM usage is 43KiB. Was certainly a lot smaller earlier today.