Systemd coredump что это
Core dump
A core dump is a file containing a process’s address space (memory) when the process terminates unexpectedly. Core dumps may be produced on-demand (such as by a debugger), or automatically upon termination. Core dumps are triggered by the kernel in response to program crashes, and may be passed to a helper program (such as systemd-coredump) for further processing. A core dump is not typically used by an average user, but may be passed on to developers upon request where it can be invaluable as a post-mortem snapshot of the program’s state at the time of the crash, especially if the fault is hard to reliably reproduce.
Contents
Disabling automatic core dumps
Users may wish to disable automatic core dumps for a number of reasons:
Using sysctl
sysctl can be used to set the kernel.core_pattern to nothing to disable core dump handling. Create this file
To apply the setting immediately, use sysctl :
Using systemd
Then reload systemd’s configuration.
This method alone is usually sufficient to disable userspace core dumps, so long as no other programs enable automatic core dumps on the system, but the coredump is still generated in memory and systemd-coredump run.
Using PAM limits
The maximum core dump size for users logged in via PAM is enforced by limits.conf. Setting it to zero disables core dumps entirely. [3]
Using ulimit
Command-line shells such as bash or zsh provide a builtin ulimit command which can be used to report or set resource limits of the shell and the processes started by the shell. See bash(1) § SHELL BUILTIN COMMANDS or zshbuiltins(1) for details.
To disable core dumps in the current shell:
Making a core dump
To generate a core dump of an arbitrary process, first install the gdb package. Then find the PID of the running process, for example with pgrep:
Attach to the process:
Then at the (gdb) prompt:
Where do they go?
Examining a core dump
Use coredumpctl to find the corresponding dump:
Pay attention to «Signal» row, that helps to identify crash cause. For deeper analysis you can examine the backtrace using gdb:
When gdb is started, use the bt command to print the backtrace:
See Debugging/Getting traces if debugging symbols are requested, but not found.
Пять инструментов systemd, которые стоит начать использовать прямо сейчас
Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.
Когда наконец удается смириться с уходом systemd от тех принципов, что лежали в основе ветхозаветной System V с ее простыми текстовыми файлами и засильем скриптов, начинаешь видеть неоспоримые преимущества новой системы инициализации и поставляемых с ней инструментов. В этой статье мы поговорим о четырех из них, а также упомянем еще один, который вы наверняка уже знаете, но вряд ли использовали описанным здесь способом.
coredumpctl
Этот инструмент, как услужливо подсказывает его имя, используется для получения дампов памяти из журнала systemd.
Команда coredumpctl вернет общий список всех дампов памяти, в котором могут быть записи за несколько недель, а то и месяцев работы системы.
Рис. 1. coredumpctl выводит список всех дампов памяти, зарегистрированных в журнале
Эта команда выведет все детали последнего дампа с PID 1758. А поскольку журнал systemd охватывает более одной сессии (мой, например, начинается с мая), в нем могут оказаться несколько не связанных друг с другом дампов от процессов с одинаковым PID.
Рис. 2. Модификатор dump позволяет получить более подробную информацию о дампе памяти
Также есть возможность установить фильтр по имени исполняемого файла:
Как и в случае с PID, эта команда выведет информацию только о последнем дампе, поскольку в большинстве случаев нужен именно он.
В фильтре дампа памяти может использоваться PID, имя исполняемого файла, путь, который должен содержать как минимум одну косую черту (например, /usr/bin/name_of_executable), а также один или несколько общих предикатов (general predicates) journalctl. Последний вариант показан в следующем примере:
Помимо dump у сoredumpctl есть и другие опции. Для тех, кто хочет сразу начать отладку, следующая команда не только выведет всю информацию о дампе, но и откроет GNU debugger (gdb):
bootctl
А вы знаете, что загрузкой теперь управляет systemd-boot, а не GRUB? Да, это очередная функция, которую подмял под себя, кажется, уже не способный остановиться systemd. Правда, это пока касается только систем с UEFI.
Обучение настройке загрузчика выходит за рамки данной статьи (если вам действительно интересно, найти полезную информацию можно здесь), однако для установки пользовательской конфигурации загрузки необходимы хотя бы базовые знания bootctl.
(Если вы новичок в Linux, не пугайтесь. Вам, скорее всего, не придется делать ничего из представленного в данном разделе. Об этом позаботится ваш дистрибутив. Все, что здесь написано, в первую очередь предназначено для энтузиастов абсолютного контроля (например, пользователей Arch Linux). Эти люди не могут спать спокойно, пока в их системе остался хотя бы один параметр, который они не пробовали подкрутить.)
Для работы с bootctl нужны права суперпользователя, поэтому обращаться с этим инструментом нужно уважительно. Одно неосторожное движение — и ваша система перестанет загружаться.
Один из самых безобидных режимов bootctl — проверка статуса загрузки. Если /boot не указывает на раздел FAT EFI напрямую, нужно вручную с помощью опции —path= указать путь к загрузочному разделу EFI. Вот как выглядит команда для моей openSUSE:
Рис. 3. Инструмент bootctl позволяет просматривать и изменять настройки программы управления загрузкой
В выводе команды можно найти опции загрузки и расположение бинарного файла загрузчика (ESP).
Измененная конфигурация загрузки устанавливается с помощью команды:
Эта команда также сгенерирует бинарный файл systemd-boot, сохранит его в boot/path/to/efi/EFI/Boot и добавит соответствующий вызов в верхнюю часть списка приоритета загрузки.
Чтобы обновить systemd-boot, выполните:
Для удаления systemd-boot из раздела EFI используйте:
Будьте осторожны с последней командой.
systemd-cgtop, systemctl и systemd-cgls
Если классический top позволяет найти процессы, больше других нагружающие CPU и активнее потребляющие память, systemd-cgtop делает то же самое для контрольных групп (cgroups).
Cgroups представляет из себя механизм разбиения и изолирования ресурсов системы для предоставления их группам пользователей и задач. Например, вы можете применить cgroups для установки ограничений на потребление памяти и CPU в системе, где работают две группы пользователей. Полное описание cgroups с примерами можно найти здесь.
systemd использует cgroups для контроля своих служб, а systemd-cgtop позволяет убедиться, что все группы ведут себя прилично. Если кто-то все-таки начал безобразничать, можно одним махом завершить работу сразу всей группы, а не разыскивать и останавливать каждый процесс в отдельности.
Взгляните на рисунок 4, где изображен пример нормально работающей системы. Никто не злоупотребляет ресурсами, и числового обозначения в строке с итогами удостоились только общие показатели активности всех групп системы. При этом я мог бы избавиться, например, от auditd, веди он себя неподобающим образом. И поскольку система без этого сервиса не остановится, так и сделаю:
И… та-дам! Его больше нет!
Рис. 4 systemd-cgtop сообщает о поведении cgroups
В данном случае у auditd.service были две связанные с ним задачи, но их могут быть сотни, особенно у групп, используемых для конечных пользователей, поэтому systemctl очень удобен для работы с cgroups.
Кстати, чтобы посмотреть, какие процессы связаны с той или иной cgroup, попробуйте команду systemd-cgls /cgroup.name
И вы увидите все процессы, работающие в подгруппе NetworkManager.
Заключение
Мы рассмотрели лишь малую часть предназначенных для системного администрирования инструментов systemd. Их, конечно, намного больше, и в следующей статье мы поговорим еще о нескольких. Также стоит помнить, что настоящая сила многих инструментов скрыта в их многочисленных опциях.
Если вы хотите получше разобраться в вопросах, связанных с systemd, рекомендую начать с идущей в комплекте документации:
Systemd coredump что это
systemd-coredump, systemd-coredump.socket, systemd-coredump@.service — Acquire, save and process core dumps
Synopsis
Description¶
Invocation of systemd-coredump В¶
The systemd-coredump executable does the actual work. It is invoked twice: once as the handler by the kernel, and the second time in the systemd-coredump@.service to actually write the data to the journal and process and save the core file.
When the kernel invokes systemd-coredump to handle a core dump, it runs in privileged mode, and will connect to the socket created by the systemd-coredump.socket unit, which in turn will spawn an unprivileged systemd-coredump@.service instance to process the core dump. Hence systemd-coredump.socket and systemd-coredump@.service are helper units which do the actual processing of core dumps and are subject to normal service management.
Configuration¶
Disabling coredump processing¶
Information about the crashed process¶
coredumpctl (1) can be used to retrieve saved core dumps independently of their location, to display information, and to process them e.g. by passing to the GNU debugger (gdb).
Data stored in the journal can be also viewed with journalctl (1) as usual (or from any other process, using the sd-journal (3) API). The relevant messages have MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 :
The following fields are saved (if known) with the journal entry
The process number (PID), owner user number (UID), and group number (GID) of the crashed process.
The time of the crash as reported by the kernel (in Вµs since the epoch).
The system unit and slice names.
When the crashed process was in a container, this is the full path, as seen outside of the container.
The numerical UID of the user owning the login session or systemd user unit of the crashed process, and the user manager unit. Both fields are only present for user processes.
The terminating signal name (with the » SIG » prefix [1] ) and numerical value. (Both are included because signal numbers vary by architecture.)
The current working directory and root directory of the crashed process.
When the crashed process is in a container, those paths are relative to the root of the container’s mount namespace.
Information about open file descriptors, in the following format:
The destination of the /proc/ pid /exe symlink.
When the crashed process is in a container, that path is relative to the root of the container’s mount namespace.
Fields that map the per-process entries in the /proc/ filesystem: /proc/ pid /comm (the command name associated with the process), /proc/ pid /exe (the filename of the executed command), /proc/ pid /status (various metadata about the process), /proc/ pid /maps (memory regions visible to the process and their access permissions), /proc/ pid /limits (the soft and hard resource limits), /proc/ pid /mountinfo (mount points in the process’s mount namespace), /proc/ pid /environ (the environment block of the crashed process).
See proc (5) for more information.
The system hostname.
When the crashed process was in container, this is the container hostname.
For processes running in a container, the commandline of the process spawning the container (the first parent process with a different mount namespace).
When the core is stored in the journal, the core image itself.
When the core is stored externally, the path to the core file.
Set to » 1 » when the saved coredump was truncated. (A partial core image may still be processed by some tools, though obviously not all information is available.)
The following fields are saved (if known) with the external file listed in COREDUMP_FILENAME= as extended attributes:
See Also¶
[1] kill (1) expects signal names without the prefix; kill (2) uses the prefix; all systemd tools accept signal names both with and without the prefix.
Linux: создание coredump памяти процесса, systemd-coredump и Debian
Возникла необходимость получить дамп РНР-процесса на Debian 9.
Рассмотрим механизм ядра, позволящий создать дамп, и настройку создания дампов в Linux.
Ниже будем говорить о создании дампа памяти процесса в Linux, а не дампа ядра при kernel panic – там он иной, см. Kdump на Arch Wiki.
Linux Core Dump
Ядро создаёт дамп памяти процесса, если он выполнил недопустимую операцию, и должен быть остановлен.
Для этого при выполнении такой операции ядро отправляет один из аварийных сигналов процессу, после чего процесс обрабатывает сигнал сам, или с помощью сторонних обработчиков, что запускает механизм ядра, который создаёт дамп.
Список таких сигналов задаётся в макросе SIG_KERNEL_COREDUMP_MASK :
Который используется в другом макросе – sig_kernel_coredump :
Который срабывает в случае Fatal-ошибок, и вызывает do_coredump() :
Ну а сама do_coredump() создаёт дамп.
Сигналы и создание дампа
Проверим работу дампа.
Берём простой код на Си:
Собираем, и запускаем:
Во второй консоли – отправляем один из сигналов, например SIGSEGV (Segmentation violation), код 11:
В окне с приложением проверяем:
Проверяем файл дампа:
Аналогично можно создать дамп практически любого процесса, например – запустим sleep :
GDB – создать core dump
GDB – прочитать core dump
kernel.core_pattern
Тут можно задать путь и имя файла, в который будет записан дамп, либо передать создание дампа внешнему обработчику, например systemd-coredump (рассмотрим ниже).
См. документацию Naming of core dump files тут>>>.
Из наиболее используемых опций тут:
Собственно файл /tmp/coredump-make_dump.2714790, который мы открыли в GDB, и состоит из kernel.core_pattern = /tmp/coredump-%e.%p :
limits.conf
Кроме имени файла – ядро проверит значение soft и hard лимитов для core в /etc/security/limits.conf :
Либо проверяем в рабочем окружении:
Лимиты конкретного процесса можно получить через его дескриптор в /proc :
fs.suid_dumpable
Определяется флагом fs.suid_dumpable :
Может принимать значение 0, 1 или 2, см. man proc:
systemd-coredump
На Arch Linux он используется по-умолчанию, на Debian 9 ставим из репозитория:
После установки настраиваем ядро – через пайп передаём создание дампа в systemd-coredump :
Создаём дамп какого-то процесса:
coredumpctl
Для работы с дампами через systemd-coredump – используем coredumpctl :
Сами файлы дампов systemd-coredump сохраняет в /var/lib/systemd/coredump :
Просмотреть дамп – передаём условие для MATCH, например – PID:
Беспредел systemd
Можно ли жить как-то без этого?
Только причём тут systemd?
В этот момент 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.
Ещё в прошлом году пару раз напоролся, поправил конфиг и забыл, как страшный сон. Но ты решил создать тему арчеболи и неосиляторства, чтобы излить свою душу.