Systemd coredump грузит процессор
I'm trying to set up systemd-coredump on Ubuntu 18.04, so that I can catch and log crashes of my C++ application for debugging.
So far, I've installed systemd-coredump version 237-3ubuntu10.47 from apt, and I'm able to trigger a crash by sending my application a segmentation fault signal:
However, I don't see a dump in /var/crash/ as I expected. Running sudo coredumpctl list does not show any crashes, either; it only replies No coredumps found.
I read the systemd-coredump manual that logs are stored in the journal, so I opened it with sudo journalctl and search for my kill command. After it, I found this error message:
I examined the directory /usr/lib/systemd/ , and I found that systemd-coredump did not exist. However, I'm not sure if this . file? ..directory? is supposed to be created on the fly. Is there perhaps a permission issue during file/directory creation, because /usr/lib/systemd/ is owned by root , while my application runs as an unprivileged user?
Here is my kernel.core_pattern configuration, /usr/lib/sysctl.d/50-coredump.conf . (It's the default.)
And my coredump configuration, /etc/systemd/coredump.conf (also the default).
I also confirmed that I have no config snippets in /etc/systemd/coredump.conf.d/ (In fact, there is no such directory.)
2 Answers 2
TL;DR: My core_pattern was being overridden by /etc/sysctl.d/core.conf .
From re-reading the systemd-coredump manual, I eventually realized that /usr/lib/systemd/systemd-coredump was not just a file or directory where dumps were logged, but it was supposed to be the systemd-coredump binary, itself. So obviously, the fact that it was not present was a problem.
I also noticed that the error in the journal showed that the kernel was looking for the systemd-coredump binary in /usr/lib/systemd/systemd-coredump , not /lib/systemd/systemd-coredump , as my configuration showed. And in fact, a binary did exist at /lib/systemd/systemd-coredump .
Therefore, my next step was to figure out why the kernel was trying to use /usr/lib/systemd/systemd-coredump . For that, I performed a recursive file search with grep . The only config file I found containing the misconfigured binary path was /etc/sysctl.d/core.conf :
Although the file /etc/sysctl.d/core.conf is not mentioned in the systemd-coredump manual, it is apparently another way to override the core_pattern , because after I commented out the kernel.core_pattern line in /etc/sysctl.d/core.conf and rebooted my VM, I was able to crash my application and see the dumps (and no error in the journal)! :)
С недавних пор я на обновлённом арче. 10 минут назад - хожу я по интернету и внезапно начинаются тормоза. Сквозь них я дотягиваюсь до эмулятора терминала и запускаю top. Вижу - какой-то systemd-coredump (примерно так называется) сожрал over 400М рамы и что-то делает. 3 минуты и всё заканчивается - гавнюк укладывается, вынудив linux пришибить лисичку. sbcl опять меня удивил - похудел с over 50М до 2М в RES, жалко в него кроме очередных foo и baz ничего загружено не было.
Можно ли жить как-то без этого?
Только причём тут systemd?
А да - в самый разгар тормозов systemd-coredump был первым в топе по потреблению RAM.
В этот момент systemd что-то должен написать в логе. Яви нам его!
Можно, выключи systemd-coredump, если у тебя часто валятся жырные говна.
Беспредел движка автомобиля. Движок ревёт, стрелка оборотов over7к. Можно ли жить без движка?
Правда у меня иногда педаль газа заедает но это фигня, сначала нужно выпилить этот двигатель.
покажет список core-дампов.
можно «спрятать голову в песок» и отключить снятие core-дампов или всё же разобраться чего у тебя там грохается.
Process 409 (firefox) dumped core.
(firefox) dumped core
firefox
причём тут systemd?
При том, что он тупит по полминуты на каждом дампе и жрёт память как ненормальный. Я хз, что он там делает с ними, с дампами этими. Может на зиму солит, в бочки закатывает.
Предыдущая версия фокса падала часто (щас пофиксили вроде), так каждый раз при падении фокса система раком встаёт из-за systemd.
На самом деле, systemd здесь причем.
Несколько дней назад в списке рассылки обсуждался вопрос тормозов systemd-coredump:
As soon as a bigger coredump (about 500 MB) is to be stored, the whole system slows down significantly. Seems like storing such big amounts of data takes pretty long and is a very CPU hungry process.
Kay Sievers обещал починить
It really always needs to be extracted to be a minidump to store away. There are no other sensible options when things should end up in the journal.
Предыдущая версия фокса падала часто
Feb01 1632:48 /home/user/firefox/firefox
Че сказать-то хотел?
Какая-то из недавних (за последние месяца 2 или 3) падала где-то раз в день. Сейчас 27-я стоит, вроде больше не падает.
это при том (реально странно (при моей неприязни к этому поделию, но уважении к качеству кодирования)), что к удивлению systemd покрывается юнит-тестами (хотя и не везде), судя по исходникам.
Если это так по словам ТС, все же присутствует некоторая рискованность использования нескриптовой базы - любой подобный чих может быть угрозой к стабильности системы.
Ты не привёл строки лога, касающиеся systemd.
По ним легко гуглится, что нужно выставить ограничение на размер файла в journald.conf.
Ещё в прошлом году пару раз напоролся, поправил конфиг и забыл, как страшный сон. Но ты решил создать тему арчеболи и неосиляторства, чтобы излить свою душу.
Ubuntu Server 16.04, веб-сервер, systemd грузит процессор все ядра в 100%. При этом ничего не тормозит.
Куда и как копать? Какие логи смотреть? Я нуб. (:
Ну посмотите последние записи логов что-то типа:
journalctl -n 100
Если там по кругу идут одинаковые сообщния, туда и копать.
Кто то ищет что бы не тормозило , а тебе наоборот надо , ты с этого мира ? В этом и прикол что лучше перфомансе чем тормозансе гпу. Дайте ему кто нибудь жируху дистр с накладками в скорости
ТС, сделай readlink -f /proc/1244/exe от root.
Как это похоже на системд.
1244 root 20 0 405156 2736 2296 S 247.1 0.1 47:07.51 systemd
Всё ништяк, init работает. :-) Хм. А что он не pid 1 ?
А вот был бы продуманный и понятный всем System V мы бы немедленно разобрали что к чему. Вот он весь леденящий кровь ужас комбайн пожинающий души неверующих в unix-way!
хорошо что хоть не svchost.exe. это в будущем
в папке dllcache
троянчег маскирующийся под системд :) бинарь запакуй и выложи позырить.
Ооо! Вот я валенок! (:
Что теперь с этим делать? Что это такое? Откуда взялось?
но малваремейкеры таки знают, подо что маскироваться, чтоб не вызывать подозрений!
залей на virustotal
Как низко мы пали
Скорее майнер какой-нибудь, троянчег не стал бы палиться расходом CPU
Блэт. Архивировал-архивировал. и удалил.
А не засланный ли ты, фраерок?
Я пока не уютно себя чувствую в посудной лавке.
Ты небось под рутом сидеть любишь?
Блэт. Архивировал-архивировал… и удалил.
Ну вот, оставил людей без семпла!
Ты небось под рутом сидеть любишь?
А есть разница от какого пользователя работал бы майнер?
Не бурчи, имеющие голову уже все разобрали без любителей Bash-лапши.
Ну блин. А я хотел холодным зимним вечерком, сидя у теплого камина и попивая чаек, дизассемблировать эту пакость и посмотреть что она делает.
Как заразился-то можешь сказать?
Если бы тс не удалил, то можно было бы сказать точно. А сейчас уже анализировать нечего. Разве что опять подцепит. Но, по опыту майнинга (на том, с чем имел дело) разница есть, точнее была. И как-то это должно было попасть в /root. Заговор спецслужб я оставил на потом. Сначала спросил про самое очевидное.
Если он не сам скачал и запустил, то скоро опять майнить начнёт. Тогда и будет образец.
столько поноса и ни один толкового ничего не посоветовал
залей куда нибудь вывод
Не пробовал дочитать тему до конца? 🤔
Не факт, что в этих файлах будет след эксплойта. Скорее всего обычный майнер, исследовать который нет смысла.
Не факт, что в этих файлах будет след эксплойта.
Не думаю, что он там вообще был. Скорее всего просто подошел пароль к ssh.
Скорее всего обычный майнер, исследовать который нет смысла.
Легко пропустить что-нибудь интересное, поэтому я стараюсь пользоваться возможностью исследовать что-либо из дикой среды.
Очень интересно где ты такое счастье подхватил. Вспоминай где лазил, что загружал, что запускал.
Что теперь с этим делать? Что это такое?
это надо выполнить в терминале из под su, если это настоящий systemd система рухнет, а если майнер система устоит и потребление cpu придет в норму
amd_amd ★★★★ ( 03.02.19 22:02:46 )
Последнее исправление: amd_amd 03.02.19 22:03:39 (всего исправлений: 1)
Я всей истории не знаю. Сервер оставили как есть - ждем возвращения. Пошел учиться архивировать.
Если ещё актуально «хотел посмотреть» и «как заразился».
Вчера поймал kdevtmpfsi в «дикой природе» - есть архив бинарей, если интересно могу предоставить.
- белый IPv4 в Инете + redis Protected-Mode no :-)
- через примерно 1 (одни) сутки от поднятия.
ну конечно, добавили в этот ваш сустемд майнер и думаете, что никто не заметит
Сложноватый способ «добавить майнера» на собственный сервер. :-)
Systen V не имеет процесса кроме /bin/sh
sudo htop - увидеть загрузку CPU по всем доступным ядрам на 100% и load average больше чем количество ядер. Записать ‘process id’ лидеров.
В моём лучае было в постоянных лидерах 6 процессов /tmp/kdevtmpfsi от пользователя systemd+ . Но ‘systemd’ не запускает файлов из ‘/tmp’…
sudo top - показывает лидером процесс kdevtmpfsi от пользователя systemd+ .
sudo ps -auxf - посмотреть в дереве процессов кто породил «пожирателя» (это ожидаемый родитель?). Тут я увидел ‘redis’ и ‘контейнер’.
sudo find / -name kdevtmpfsi и sudo find / -name 'kinsing*' - найти на файловой системе место, где располагаются файлы «врага».
ls -la --time-style=full-iso /tmp - по датам создания файлов в найденных каталогах можно примерно понять время атаки. Это сильно условно, так как атрибуты файлов можно было и поменять.
Люди пишут, что запуск прописывает в crontab . У меня - не нашелся.
sudo grep CRON /var/log/syslog - должны увидеть периодический запуск странного.
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done - посмотреть в расписания заданий пользователей, может прятаться у пользователя ‘www-data’ или других.
И совет: скопрометированный хост надо переставлять, а не пытаться «чистить»!
Wise Penguin
systemd-coredump 100% cpu usage
recently systemd-coredump has been constantly using 100% cpu.
I'm not sure how long this has been going on but certainly for the last several days at least.
The usage appears to be constant and never falls below 100% cpu usage.
coredumpctl list shows hundreds of lines of the following . . .
Shaman Penguin
Originally Posted by farcusnz
Tracker is segfaulting and causing it to coredump. Bug in tracker or perhaps its database is corrupted - you are definitely not alone, we've had a few people with the same issue come to IRC.
Uninstall tracker or disable coredumps? ( ln -s /dev/null /etc/sysctl.d/50-coredump.conf disables coredumps, or at least should )
Wise Penguin
Originally Posted by Miuku
Tracker is segfaulting and causing it to coredump. Bug in tracker or perhaps its database is corrupted - you are definitely not alone, we've had a few people with the same issue come to IRC.
Uninstall tracker or disable coredumps? ( ln -s /dev/null /etc/sysctl.d/50-coredump.conf disables coredumps, or at least should )
but systemd-coredump is still hogging the cpu after reboot.
edit: have uninstalled Tracker which has alleviated the symptoms for now.
What are the consequences of removing Tracker?
Shaman Penguin
Let's try another way: ln -s /dev/null /usr/lib/sysctl.d/50-coredump.conf
It's possible the override won't work and you need to replace the main coredump file.
Wise Penguin
Originally Posted by Miuku
I don't use Gnome either but got Tracker as part of a default 42.3 / Plasma 5.8.x install.
I guess I don't really need tracker if it is part of gnome then?
Administrator
On Sun 10 Sep 2017 03:26:01 AM CDT, farcusnz wrote:
Miuku;2837435 Wrote:
> Tracker is segfaulting and causing it to coredump. Bug in tracker or
> perhaps its database is corrupted - you are definitely not alone,
> we've had a few people with the same issue come to IRC.
>
> Uninstall tracker or disable coredumps? ( *ln -s /dev/null
> /etc/sysctl.d/50-coredump.conf* disables coredumps, or at least
> should )
thanks.
I've tried running
but systemd-coredump is still hogging the cpu after reboot.
Shaman Penguin
Originally Posted by farcusnz
Have you, at any point, used GNOME? I'm wondering how it got installed because I don't have it.
Either way, KDE uses its own file search and management so it shouldn't cripple anything.
Flux Capacitor Penguin
Originally Posted by Miuku
Have you, at any point, used GNOME? I'm wondering how it got installed because I don't have it.
Either way, KDE uses its own file search and management so it shouldn't cripple anything.
Wise Penguin
Originally Posted by Miuku
Have you, at any point, used GNOME? I'm wondering how it got installed because I don't have it.
Either way, KDE uses its own file search and management so it shouldn't cripple anything.
No. I've never used or installed Gnome.
Brasero was installed (which I think is part of pattterns-opensuse-multimedia) so perhaps that is the link. I no longer have it though
systemd-coredump collects and displays kernel core dumps, for analyzing application crashes. When a process crashes (or all processes belonging to an application), its default is to log the core dump to the systemd journal, including a backtrace if possible, and to store the core dump in a file in /var/lib/systemd/coredump . You also have the option to examine the dump file with other tools such as gdb or crash (see Section 18.8, “Analyzing the crash dump”). There is an option to not store core dumps, but to log only to the journal, which may be useful to minimize the collection and storage of sensitive information.
systemd-coredump is enabled and ready to run by default. The default configuration is in /etc/systemd/coredump.conf :
The following example shows how to use Vim for simple testing, by creating a segfault to generate journal entries and a core dump.
Enable the debuginfo-pool and debuginfo-update repositories
Launch vim testfile and type a few characters
Get the PID and generate a segfault:
Vim will emit error messages:
List your core dumps, then examine them:
When you have multiple core dumps, coredumpctl info displays all of them. Filter them by PID , COMM (command), or EXE (full path to the executable), for example, all core dumps for Vim:
See a single core dump by PID :
Output the selected core to gdb :
The asterisk in the PRESENT column indicates that a stored core dump is present. If the field is empty there is no stored core dump, and coredumpctl retrieves crash information from the journal. You can control this behavior in /etc/systemd/coredump.conf with the Storage option:
Storage=none —core dumps are logged in the journal, but not stored. This is useful to minimize collecting and storing sensitive information, for example for General Data Protection Regulation (GDPR) compliance.
Storage=external —cores are stored in /var/lib/systemd/coredump
Storage=journal —cores are stored in the systemd journal
A new instance of systemd-coredump is invoked for every core dump, so configuration changes are applied with the next core dump, and there is no need to restart any services.
Core dumps are not preserved after a system restart. You may save them permanently with coredumpctl . The following example filters by the PID and stores the core in vim.dump :
See man systemd-coredump , man coredumpctl , and man coredump.conf for complete command and option listings.
Читайте также: