3.2.12.11 Настройка systemd-coredump для автоматического сбора дампов
Скачать документ Настройка сбора дампов
Изменение места сохранения дампов
Проверка работоспособности создания дампа
Чтение дампов ядра
Настройка сбора дампов в СУБД Ред База Данных
Окружение
- Версия РЕД ОС: 8
- Конфигурация: Рабочая станция
- Версия ПО: systemd-246.10-16
Дамп памяти (core dump) — содержимое рабочей памяти одного процесса, ядра или всей операционной системы. Также может включать дополнительную информацию о состоянии программы или системы, например, значения регистров процессора и содержимое стека. Многие операционные системы позволяют сохранять дамп памяти для отладки программы. Как правило, дамп памяти процесса сохраняется автоматически, когда процесс завершается из-за критической ошибки (например, из-за ошибки сегментации). Дамп также можно сохранить вручную через отладчик или любую другую специальную программу.
Настройка сбора дампов
В РЕД ОС 7.3 для автоматического сбора дампов используется обработчик дампов systemd-coredump — он собирает информацию о процессе при аварийном завершении программы. Для проверки сбора дампов выполните команду:
cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
Размер дампов определяется в файле конфигурации /etc/systemd/coredump.conf. Для изменения размера дампов в секции [Coredump]
необходимо раскомментировать следующие параметры:
Compress=yes
ProcessSizeMax=<максимальный_размер_дампов>
ExternalSizeMax=<максимальный_размер_сжатого_дампа>
Далее будут подробнее рассмотрены параметры конфигурационного файла:
Storage
— определяет место хранения дампа процесса, может принимать одно из значений: none, external, journal.none — дампы ядра записываются (включая обратную трассировку, если возможно), но не сохраняются;
external — значение по умолчанию, дампы сохраняются в каталоге /var/lib/systemd/coredump/;
journal — дампы будут храниться в журнале и перезаписываться в соответствии со стандартными принципами ротации журналов.
Compress
— используется для сжатия дампов ядра. Принимает логический аргумент — yes или no:yes — дампы сжимаются при сохранении (значение по умолчанию);
no — дампы сохраняются без сжатия.
ProcessSizeMax
— определяет максимальный размер дампа процесса, который может быть сохранен. Если размер дампа превышает значение этого параметра, то дамп сохранен не будет. Это позволяет ограничить размер дампов и избежать переполнения дискового пространства. Значение параметра указывается в байтах, также возможно использование суффиксов (B, K, M, G, T, P и E). По умолчанию до 1ГБ — в 32-битных системах, 32ГБ — в 64-битных системах. ПараметрыStorage=none
иProcessSizeMax=0
отключает всю обработку дампа памяти, за исключением записи журнала.ExternalSizeMax
иJournalSizeMax
— определяет максимальный (сжатый или несжатый) размер дампа процесса, который будет сохранен на диске (по умолчанию 1 ГБ — в 32-разрядных системах, 2 ГБ — в 64-разрядных системах), или в журнале системы (по умолчанию 10М).MaxUse
— определяет максимальный объем общего дискового пространства, который может быть использован для хранения дампов процессов. Если общий размер всех дампов превышает значение этого параметра, старые дампы будут удаляться для освобождения места для новых. Значение параметра указывается в байтах, также возможно использование суффиксов (B, K, M, G, T, P и E). По умолчанию ограничение равно 10% от общего размера диска.KeepFree
— определяет минимальный объем свободного дискового пространства, который должен оставаться на диске при хранении дампов. Если свободного места на диске становится меньше указанного значения, новые дампы не будут создаваться до тех пор, пока не будет предоставлено достаточного объема свободного пространства. Значение параметра указывается в байтах, также возможно использование суффиксов (B, K, M, G, T, P и E). По умолчанию 15% от общего размера диска должно оставаться свободным. Старые дампы ядра также удаляются в зависимости от времени с помощью systemd-tmpfiles.
Изменение места сохранения дампов
Дампы по умолчанию будут создаваться в каталоге /var/lib/systemd/coredump. Служба systemd-coredump не имеет параметра конфигурации для изменения каталога, в котором будут храниться дампы.
Для смены каталога создания дампов необходимо использовать bind-mount:
1. В файле /etc/fstab пропишите монтирование нужной директории для сохранения дампов следующим образом:
/каталог/для/дампов /var/lib/systemd/coredump none defaults,bind 0 0
2. Примонтируйте каталог:
mount /var/lib/systemd/coredump
3. Перезапустите службу systemd для применения изменений:
systemctl daemon-reload
Проверка работоспособности создания дампа
Для проверки создания дампа необходимо выполнить в терминале:
sleep 3600 & kill -11 %1
Проверьте создание дампа с помощью утилиты coredumpctl:
coredumpctl
Рассмотрим дополнительные опции coredumpctl:
list — список доступных дампов ядра;
info <PID> — вывод подробной информации об указанном дампе ядра;
gdb <файл> — запускает отладчик gdb (GNU Debugger) для анализа дампа ядра;
dump <PID> — создает дамп ядра с указанным идентификатором (PID). Дамп ядра будет передан на стандартный вывод, если не указан выходной файл с помощью --output=;
debug <PID> — запуск процесса с указанным PID в режиме отладки. По умолчанию используется gdb. Отладчик может быть изменен с помощью параметра --debugger= или переменной среды $SYSTEM_DEBUGGER. Для передачи отладчику дополнительных аргументов командной строки используется параметр --debugger-arguments=.
Чтение дампов ядра
Сводную информацию о дампе ядра, соответствующем определенному процессу, в котором произошел сбой, можно получить, выполнив команду:
coredumpctl info _PID=<PID_процесса,по_которому_создан_дамп>
Для полного чтения дампа необходимо установить утилиту gdb, выполнив команду (с правами суперпользователя root или администратора системы):
dnf install gdb
Запустите анализ дампа, выполнив команду:
coredumpctl gdb _PID=<PID_процесса,по_которому_создан_дамп>
Настройка сбора дампов в СУБД Ред База Данных
Для сбора дампов СУБД Ред База Данных необходимо в файл службы /usr/lib/systemd/system/firebird.service в секцию [Service]
добавить строку:
LimitCORE=infinity
Для этого необходимо воспользоваться редактированием модуля юнита с помощью команды:
systemctl edit firebird
И добавить следующие строки:
[Service]
LimitCORE=infinity
После сохранения сформируется файл /etc/systemd/system/firebird.service.d/override.conf.
При загрузке модуля systemd в памяти соединит фрагмент сформированного файла (/etc/systemd/system/firebird.service.d/override.conf) с полным файлом модуля (/usr/lib/systemd/system/firebird.service). Директивы фрагмента получат приоритет над найденными директивами в оригинальном файле модуля. Для проверки всех подгружаемых фрагментов необходимо выполнить:
systemctl cat firebird
Если СУБД при работе потребляет большой объем памяти (настроен большой страничный кэш), то создание дампа на диске после падения может продолжаться некоторое время. В конфигурационном файле службы coredump может быть настроен таймаут работы, после которого она будет остановлена. Для того чтобы времени на создание дампа было достаточно, необходимо увеличить таймаут, например, до 30 минут, изменив значение параметра RuntimeMaxSec
в файле /usr/lib/systemd/system/systemd-coredump@.service:
RuntimeMaxSec=30min
Дампы ядра полезны для устранения неполадок, однако могут являться причиной “утечки” конфиденциальных данных. Рекомендуется отключать дампы ядра и включать их только тогда, когда это действительно необходимо.
Для отключения сбора дампов ядра необходимо остановить службу systemd-coredump:
systemctl disable systemd-coredump systemctl stop systemd-coredump
Дата последнего изменения: 25.09.2024
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.