dbus-broker uses an extremely high amount of memory about dbus-broker

[BrainDamage]

Thanks for the help, I've managed to find the root cause.

I had a systemd user service with auto-restart enabled, the service kept crashing and the stacktraces being dumped to coredumpctl every few s. Eventually the queue kept increasing to the point of allocating the mentioned ram amount. I aso learned a lesson next time to skim the global journal first instead of filtering on a per-unit output.

[dvdhrm]

Your statistics-dump shows a connection with ID 1.82 (PID: 8838, UID: 1000) to have a huge amount of messages queued, which it does not process:

dict entry(
   string "OutgoingBytes"
   uint32 535562975
)

This is 500MiB of messages queued for the mentioned connection. It is also very close to exceeding the quota for UID 1000 (190605 of 536870912 bytes remaining before the quota will be exceeded).

This means there is a program on your machine running, which asked to receive D-Bus messages, but does not dispatch those messages. Hence, they will pile up until a quota is exceeded.

I assume the PID/connection-ID changes on each reboot. So if you see this happening again, use the same method to acquire the statistics-dump and search for OutgoingBytes until you find an entry with a high value. Shortly above it, the dump will show the connection-id, PID, UID, etc. (you can use busctl to show all connection IDs currently in use).

I also wrote a short explanation on how to find such D-Bus processes: https://dvdhrm.github.io/2021/04/14/locating-dbus-resource-leaks/

Let me know if you need more help!