Настройка сбора дампов Изменение места сохранения дампов Проверка работоспособности создания дампа Чтение дампов ядра Настройка сбора дампов в СУБД Ред База Данных
Окружение
Дамп памяти (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] необходимо раскомментировать следующие параметры:
[Coredump]
Compress=yes ProcessSizeMax=<максимальный_размер_дампов> ExternalSizeMax=<максимальный_размер_сжатого_дампа>
Далее будут подробнее рассмотрены параметры конфигурационного файла:
Storage
none — дампы ядра записываются (включая обратную трассировку, если возможно), но не сохраняются;
external — значение по умолчанию, дампы сохраняются в каталоге /var/lib/systemd/coredump/;
journal — дампы будут храниться в журнале и перезаписываться в соответствии со стандартными принципами ротации журналов.
Compress
yes — дампы сжимаются при сохранении (значение по умолчанию);
no — дампы сохраняются без сжатия.
ProcessSizeMax — определяет максимальный размер дампа процесса, который может быть сохранен. Если размер дампа превышает значение этого параметра, то дамп сохранен не будет. Это позволяет ограничить размер дампов и избежать переполнения дискового пространства. Значение параметра указывается в байтах, также возможно использование суффиксов (B, K, M, G, T, P и E). По умолчанию до 1ГБ — в 32-битных системах, 32ГБ — в 64-битных системах. Параметры Storage=none и ProcessSizeMax=0 отключает всю обработку дампа памяти, за исключением записи журнала.
ProcessSizeMax
Storage=none
ProcessSizeMax=0
ExternalSizeMax и JournalSizeMax — определяет максимальный (сжатый или несжатый) размер дампа процесса, который будет сохранен на диске (по умолчанию 1 ГБ — в 32-разрядных системах, 2 ГБ — в 64-разрядных системах), или в журнале системы (по умолчанию 10М).
ExternalSizeMax
JournalSizeMax
MaxUse
KeepFree — определяет минимальный объем свободного дискового пространства, который должен оставаться на диске при хранении дампов. Если свободного места на диске становится меньше указанного значения, новые дампы не будут создаваться до тех пор, пока не будет предоставлено достаточного объема свободного пространства. Значение параметра указывается в байтах, также возможно использование суффиксов (B, K, M, G, T, P и E). По умолчанию 15% от общего размера диска должно оставаться свободным. Старые дампы ядра также удаляются в зависимости от времени с помощью systemd-tmpfiles.
KeepFree
Дампы по умолчанию будут создаваться в каталоге /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] добавить строку:
[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
RuntimeMaxSec=30min
Дампы ядра полезны для устранения неполадок, однако могут являться причиной “утечки” конфиденциальных данных. Рекомендуется отключать дампы ядра и включать их только тогда, когда это действительно необходимо.
Для отключения сбора дампов ядра необходимо остановить сокет systemd-coredump:
systemctl disable systemd-coredump.socket systemctl stop systemd-coredump.socket
Дата последнего изменения: 14.02.2025
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.
Нажимая «Отправить запрос», вы соглашаетесь с условиями обработки персональных данных.
Вы будете получать только актуальную информацию по обновлению безопасности
Подписываясь на уведомления, вы соглашаетесь с условиями обработки персональных данных.
На ваш почтовый адрес отправлено письмо с подтверждением подписки.