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

vasek, нееее нет...
фишка в том что, занимаемая память dbus это какая то структура. а у этой структуры есть четкое определение какой другой процесс инициировал выделение памяти для него.
так вот я хотел бы проанализировать выделенную память на предмет совпадений на процесс спамер. (подозреваю что этот процесс всего одни.)
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
а у этой структуры есть четкое определение какой другой процесс инициировал выделение памяти для него
То есть - запросил dbus-daemon для своих нужд дополнительной памяти - и нужно узнать причину запроса?, точнее, кто инициатор?
Здесь дамп памяти не поможет - нужен другой инструмент, например, наиболее простой это strace - там будет указан системный вызов mmap (выделение памяти), а выше может что то и будет об инициаторе, но этим никогда не интересовался, а потому будет ли там что то указано и как, сказать не могу.
В приведенном выше скрипте указан gdb, но, думаю, в части выявления инициатора вряд ли с помощью этого отладчика что то можно выяснить.

И все-таки, для начала неплохо бы набрать информации - какой процесс dbus-daemon (system или session) тратит много памяти, далее, используя pmap определить на что идет эта память? ... а уж дальше думать, можно ли и как выявить этого инициатора.
Ошибки не исчезают с опытом - они просто умнеют
Пришла еще одна идея, как можно определить виновника - использовать для этого сам dbus.
Запускаем busctl list и узнаем имена действующих юнитов, тех, что активированы (не активированный выделены серым цветом, а активированные белым) и далее запускаем мониторить по одному, чтобы определить который очень часто спамит, командой, типа
sudo busctl monitor org.freedesktop.PolicyKit1
Monitoring bus message stream.
При этом можно смотреть идет ли увеличение памяти - завершить - Ctrl+C
Если нашли такой, то можно попробовать его деактивировать и посмотреть что будет .... а можно и проще, не мониторить, а деактивировать поочередно.

PS - но можно ли таким образом выявить виновника - 100% уверенности нет. ... и вроде бы у dbus есть функция debug, но ни разу ее не запускал.

EDIT 1 - и все забываю спросить - а не пробовал ограничить размер памяти dbus??? - вроде бы по дефолту прописан 1G
Ошибки не исчезают с опытом - они просто умнеют
В части скритпа
nafanja
#!/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
насколько понимаю его работу, данный скрипт считывает область памяти, указанную в /proc/PID/maps, приаттачивается к процессу отладчиком gdb, считывает этот кусок памяти и пишет в файл … и этих файлов будет столько же сколько областей памяти в /proc/PID/maps --- и вряд ли что то будет про процессы.
Если уж так хочется снять дамп процесса, то можно это сделать и подругому, используя утилиту gcore из пакета gdb - получишь полный дамп памяти процесса, но размер может быть большим, так как это полная память занятая процессом … и далее можно анализировать этот дамп самим gdb или используя strings - смотреть строки понятные человеку … но это большой труд и не уверен, будет ли там нужная тебе информация.
Пример, как это можно провернуть
В качестве подопытного возмем PID=432 /usr/bin/dbus-daemon --session
- делаем полный дамп PID=432 с выводом в файл ~/dump
sudo gcore -o ~/dump 432
В результате получим файл ~ /dump.432 (утилита автоматом допишет PID в конец)
Смотрим размер полученного файла
stat -c %s ~/dump.432 - 2766872
Это файл elf
file ~/dump.432
/home/vasek/dump.432: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/dbus-daemon', real uid: 1000, effective uid: 1000, real gid: 100, effective gid: 100, execfn: '/usr/bin/dbus-daemon', platform: 'x86_64'
и чтобы его посмотреть нужно вытащить из него читаемые строки, используя strings
strings ~/dump.432 > ~/dump_stings.432 (один нюанс - по дефолту будут только строки длиной более 4-х символов)
Смотрим объем полученного файла
stat -c %s ~/dump_strings.432 - 282796
ну и посмотрим что там внутри (1-ые 10 строк)
cat ~/dump_strings.432 | head -10
/lib64/ld-linux-x86-64.so.2
libdbus-1.so.3
_ITM_deregisterTMCloneTable
__gmon_start__
_ITM_registerTMCloneTable
_dbus_list_get_first
dbus_connection_preallocate_send
_dbus_credentials_new_from_current_process
_dbus_string_append_byte
dbus_connection_set_max_received_unix_fds
Как то так, но поможет ли это тебе, не уверен.

PS - обычно дампы анализируют gbd, но работа с ним не так и проста - у меня так и не хватило терпения освоить его ... хотя по правде не особо это и интересовало, достаточно было получение одного Call Trace.
Ошибки не исчезают с опытом - они просто умнеют
vasek
User6260
Единственное, я последний раз обновлял систему около 2-х недель назад.
Отпишись после обновления.

Вот после вчерашнего обновления ситуация
systemctl status dbus | egrep 'Active|Memory|CPU'
     Active: active (running) since Sun 2021-11-28 11:05:23 +07; 4h 52min ago
     Memory: 5.1M
        CPU: 268ms

Вроде все хорошо. Я тут в теме прочитал, что может быть виноваты драйвера NVIDIA. У меня NVIDIA, драйвера версии 340 (у меня старая видюшка, уже не поддерживается современными драйверами).
vasek, я тебя понял а ты меня нет.
представь dbus это почтальон и у него есть сумка с письмами, так вот (мне кажется) эта сумка и раздувается от количества писем. а у письма есть отправитель, получатель и данные. вот я и хочу узнать кто отправитель и получатель проанализировав письма в сумке почтальона.
а ты предлагаешь другой метод, следить за почтальоном, у кого он берет письма.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
у письма есть отправитель, получатель и данные. вот я и хочу узнать кто отправитель и получатель
dbus-monitor busctl
User6260
Пользуюсь KDE …. после вчерашнего обновления Вроде все хорошо
Как видим у кого то все нормально, у кого то нет - напрашивается простое сравнение задействованных процессов - может так и поймается багованный?
Предлагаю сравнить выводы
busctl list --user | sed '/(activatable)/d' | awk '{print $3}'
думаю, достаточно одних user, system можно и не сравнивать ... Например, мой вывод - проблем нет
PROCESS
pulseaudio
systemd
gvfsd-fuse
at-spi2-registr
at-spi2-registr
palemoon
palemoon
pcmanfm
gvfsd-metadata
gvfs-udisks2-vo
gvfs-gphoto2-vo
gvfs-afc-volume
gsettings-helpe
gvfs-mtp-volume
gvfsd-trash
gvfsd-computer
mako
dconf-service
tilix
gvfsd-network
gvfsd-dnssd
gedit
waybar
gedit
busctl
waybar
tilix
at-spi-bus-laun
gvfsd
dconf-service
tilix
waybar
pulseaudio
at-spi-bus-laun
systemd
mako
systemd
gedit
gvfs-afc-volume
gvfsd
gvfs-gphoto2-vo
gvfs-mtp-volume
gvfsd-metadata
gvfs-udisks2-vo
gvfsd-trash
gvfsd-computer
gvfsd-network
gvfsd-dnssd
pulseaudio
Ошибки не исчезают с опытом - они просто умнеют
vs220
dbus-monitor busctl
да может быть, но это только один из многих инструментов.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vasek
Как видим у кого то все нормально, у кого то нет
Постоянно смотрю этот топик.
Наконец добрались руки дома, до четвёртого компа с KDE.
B вот на нём наконец случилось чудо :)
[wolf@wolf-pc ~]$ systemctl status dbus | grep Memory
     Memory: 26.6M
Вчера, за шесть часов работы набежало 387MB, но больше не подымалось уже.

P.S. пока писал сообщение, уже набежало:
[wolf@wolf-pc ~]$ systemctl status dbus | grep Memory
     Memory: 29.5M
 
Зарегистрироваться или войдите чтобы оставить сообщение.