dbus-daemon сжирает 500 мегабайт оперативки и выше

Установлен dbus-broker. Память не течёт. Но в стандартном приложении KDE "Системный монитор" в инструменте "Приложения" можем наблюдать 4 замечательных процесса (картинка).


Удаляем dbus-broker и используем стандартный dbus-daemon. Память тут же потекла. Зато никаких 4 замечательных процессов мы уже НЕ наблюдаем (картинка).


Информация к размышлению :) Мнения и соображения приветствуются.
Насколько я понял проблема утечки dbus-broker решена - смотрим самый последний пост (Apr 14, 2021) в приведенной выше статье на GitHub
I summarized how we found the resource leak in openQA and fixed it. Maybe this serves as help to others facing similar problems and trying to make sense of it:
https://dvdhrm.github.io/2021/04/14/locating-dbus-resource-leaks/
Ошибки не исчезают с опытом - они просто умнеют
vasek
dbus-broker
временное решение,... как починять стандартный dbus, вернусь обратно на него.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
vasek, подскажи, как сдампить всю память процесса в файл?
вот сам нашел где то скриптик
#!/usr/bin/env bash

grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
    gdb --batch --pid $1 -ex \
        "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done
vasek, как думаешь подойдет? мне просто интересно посмотреть чем же забиваются сотни мегабайт...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vall
4 замечательных процесса (картинка).
???
vall
процесса
Отдельно показывает сервисы .
Первый https://archlinux.org/packages/?name=xdg-desktop-portal-kde
Нужен нет решать вам , для флатпаков, вайланда и прочих изолированных штук
Второй кскрин - два монитора, проэктор , опять же надо/нет
Третий поддержка для людей с ограниченными возможностями, если надо оставляете, если нет можно выпилить через конфиг
пакмана.
Четвертое не
знаю что
Кошелек скорее всего KDE Wallet или подобное
Во-первых, спасибо за разъяснение. Мне было вообще неясно.

Во-вторых, моя мысль в том, что !возможно! dbus-broker выставляет их "за скобки". А при стандартном dbus-daemon именно они, где-то "внутри" и текут. Но это детали предположения. Главная идея в том, что всё же в данном случае виновник ситуации -- баг KDE. Заключение умозрительное.
nafanja
нашел где то скриптик
Вряд ли что то получится выяснить, не рекомендую.

nafanja
просто интересно посмотреть чем же забиваются сотни мегабайт
Разумнее для начала использовать самые простые и понятные способы, например
1. Сначала выяснить какой демон течет: system или session? - скорее всего session
- узнаем PID процессов
ps aux | grep dbus (лишнее выкинул)
PID               process
279      dbus-daemon --system
421      dbus-daemon --session
481      dbus-daemon --config-file
- узнаем какой <PID>, который течет намного больше других, для чего периодически (раза 3, думаю, будет достаточно) смотрим выводы (лишнее выкинул)
top -n 1 -p 279,421,481
 PID USER      PR   VIRT    RES    SHR    COMMAND
    279 dbus       20     12696   6240   5024     dbus-daemon
    421 vasek      20    12580   6104   4932     dbus-daemon
    481 vasek      20    12028   5284   4624     dbus-daemon
и выясняем этот <PID>
2. анализ <PID>, который течет намного больше других ( раза 2, думаю, будет достаточно)
pmap -x -p <PID> … можно вывести и в файл
… привожу примерный вывод
pmap -x 421
 Address                Kbytes     RSS   Dirty Mode  Mapping
000055f11d763000      32      32       0       r---- dbus-daemon
000055f11d76b000     128     128     0       r-x-- dbus-daemon
000055f11d78b000      52      48       0       r---- dbus-daemon
000055f11d798000       8       8        8        r---- dbus-daemon
000055f11d79a000       4       4        4        rw--- dbus-daemon
000055f11f625000     684    556    556     rw---   [ anon ]
00007f0441c94000       8       8       0        r---- libffi.so.8.1.0
00007f0441c96000      24      24     0        r-x-- libffi.so.8.1.0
00007f0441c9f000       4       4       4        rw--- libffi.so.8.1.0
00007f0441ca0000     164     164   0        r---- libp11-kit.so.0.3.0
00007f0441cc9000     632      88    0       r-x-- libp11-kit.so.0.3.0
…..
total kB                 12584    6108    1176
PS - кстати, значения 12584 6108 в последней строчке совпадают с значениями в top (колонки VIRT и RES)
Последняя колонка в pmap - показаны библиотеки и др., что занимает память, по которым можно и узнать процесс, которому они принадлежат. Нужно смотреть, что добавилось … но, предположу, что будет добавляться anon, но возможно и ошибаюсь.
На мой взгляд, этот анализ хоть и муторный, но понятный ... поможет ли это? - 100% уверенности нет.

EDIT 1 - если будет увеличиваться память самого dbus-daemon, что похоже самое вероятное, то значит идет утечка памяти ... и как писал выше, что разумнее тестить на утечку памяти.
Ошибки не исчезают с опытом - они просто умнеют
vall
виновник ситуации
Если дело в баге очереди то все же предположительно имхо виновник дбус демон, так как не может нормально обрабатывать такие ситуации. Дбус брокен нацелен именно на предотвращение такого поведения.
Может vasek с nafanja конкретней что выяснят.

Понаблюдайте за потреблением этих процессов растет ли за несколько часов сильно.
nafanja, и все-таки наиболее вороятнее идет утечка памяти и разумнее потестить на утечку памяти - то есть никакие дополнительные процессы в pmap не появятся, а только добавяться новые адреса (о чем и дополнил предыдущий пост).
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.