Диагностика падений Linux-сервисов с coredumpctl и GDB: от дампа до причины сбоя

Когда Linux-сервис аварийно завершается, одного сообщения Failed в systemd недостаточно. Сначала зафиксируйте время сбоя и PID, затем сопоставьте записи journalctl с событием в coredumpctl, сохраните метаданные и дамп, откройте core dump вместе с тем же исполняемым файлом в GDB и проверьте внешние ограничения: OOM killer, права, SELinux, AppArmor, лимиты systemd и cgroup.

Короткий маршрут выглядит так: systemctl status SERVICE, journalctl -u SERVICE, coredumpctl list, coredumpctl info, coredumpctl dump, затем gdb EXECUTABLE CORE. Core dump показывает состояние процесса в момент завершения. Первопричину подтверждают сопоставлением backtrace, журналов и состояния системы.

Команды ниже подходят для Debian, Ubuntu и RHEL-подобных систем с systemd. Названия пакетов и наличие debug symbols могут отличаться, поэтому перед установкой проверяйте используемый пакетный менеджер и версию systemd.

Как найти причину падения Linux-сервиса за несколько шагов

Короткий алгоритм расследования

1. Зафиксируйте сервис, время аварии, PID, код возврата и сигнал.
2. Сохраните журнал unit-файла и сообщения ядра до перезапуска и очистки артефактов.
3. Проверьте, создался ли core dump, через coredumpctl list.
4. Получите метаданные командой coredumpctl info.
5. Скопируйте дамп в защищенный каталог командой coredumpctl dump.
6. Проверьте соответствие исполняемого файла, версии пакета и Build ID.
7. Откройте core dump в GDB и получите backtrace всех потоков.
8. Сопоставьте стек вызовов с журналом, OOM-сообщениями, отказами доступа и лимитами systemd.
9. Сформулируйте первопричину в формате: симптом, доказательство, причина, исправление, контрольная проверка.

SERVICE=my-service.service
journalctl -u "$SERVICE" --since "30 min ago" --no-pager
systemctl status "$SERVICE" --no-pager
coredumpctl list --since "30 min ago"

До повторного запуска сохраните вывод в закрытый каталог расследования. Перезапуск может изменить PID, удалить временные файлы и усложнить корреляцию по времени.

Какие признаки подтверждают причину

Факт падения, непосредственный сигнал, место в стеке и первопричина относятся к разным уровням анализа. Например, SIGSEGV сообщает о нарушении доступа к памяти, но кадр внутри библиотеки может быть следствием некорректного указателя, который сформировался выше по стеку. SIGABRT часто указывает на abort(), assert или намеренное аварийное завершение. SIGKILL требует проверки OOM killer, systemd и внешнего управляющего процесса, потому что полноценного состояния процесса после такого сигнала обычно нет.

Достоверный вывод строится на нескольких совпадениях: событие произошло в нужный момент, PID совпадает, бинарный файл соответствует дампу, backtrace воспроизводится, а журнал и состояние ресурсов подтверждают одну гипотезу. Одна строка журнала редко доказывает первопричину.

Проверка systemd-coredump и включение сбора core dump

Проверка systemd-coredump и обработчика ядра

Сначала проверьте, установлен ли компонент обработки дампов, активен ли socket и куда ядро передает core dump.

command -v coredumpctl
coredumpctl --version
systemctl status systemd-coredump.socket --no-pager
cat /proc/sys/kernel/core_pattern
journalctl -u systemd-coredump --since "1 hour ago" --no-pager

В системе с systemd-coredump в /proc/sys/kernel/core_pattern часто находится pipe-обработчик, который передает данные службе systemd-coredump. Точное значение зависит от дистрибутива и версии systemd. Наличие команды coredumpctl само по себе не доказывает, что дампы сохраняются: обработчик может быть отключен, лимит может равняться нулю, а хранилище может быть заполнено.

Проверьте версию операционной системы и systemd:

cat /etc/os-release
systemctl --version
uname -r

На Debian и Ubuntu пакет с обработчиком может быть отдельным компонентом systemd. В RHEL-подобных системах доступность пакета и debug symbols зависит от подключенных репозиториев и версии дистрибутива. Используйте поиск средствами пакетного менеджера, не подставляйте имя пакета вслепую.

Проверка лимита core-файлов для сервиса

Лимит интерактивной оболочки и лимит systemd относятся к разным контекстам. Проверка ulimit полезна для ручного запуска, а для unit-файла нужно смотреть эффективное значение LimitCORE.

ulimit -c
systemctl show "$SERVICE" -p LimitCORE -p LimitNOFILE -p LimitNPROC -p MemoryMax -p TasksMax -p OOMPolicy
systemctl cat "$SERVICE"

Значение LimitCORE=0 запрещает процессу создавать core dump через обычный механизм лимитов. Для временной проверки можно создать drop-in, а затем убрать его после расследования:

sudo systemctl edit "$SERVICE"

В открывшемся редакторе задайте:

[Service]
LimitCORE=infinity

После сохранения проверьте конфигурацию и перезапустите сервис контролируемо:

sudo systemctl daemon-reload
systemctl show "$SERVICE" -p LimitCORE
sudo systemctl restart "$SERVICE"

Изменение лимита не заставляет уже завершившийся процесс создать дамп. Оно влияет на последующие падения. На production-системе сначала оцените свободное место и размер процесса.

Настройки хранения в coredump.conf

Конфигурация systemd-coredump обычно находится в /etc/systemd/coredump.conf или в drop-in-файлах внутри /etc/systemd/coredump.conf.d/. Узнать активные параметры можно через справку и просмотр файлов конфигурации:

systemd-analyze cat-config systemd/coredump.conf
systemctl show systemd-coredump.service --no-pager

Для хранения используют Storage=external, Storage=journal или значение, выбранное дистрибутивом по умолчанию. ProcessSizeMax ограничивает размер обрабатываемого дампа процесса. ExternalSizeMax ограничивает размер внешнего файла. MaxUse задает максимальный объем хранилища, а KeepFree оставляет свободное место на файловой системе. Compress включает сжатие внешних дампов, если оно поддерживается текущей версией.

Перед изменением оцените размер процесса и диска:

free -h
df -hT
coredumpctl list

После изменения конфигурации перечитайте параметры и примените их способом, предусмотренным вашей версией systemd. Для настроек, которые читает обработчик при запуске, может потребоваться перезапуск socket или соответствующего компонента. Не перезапускайте systemd целиком ради изменения одного параметра.

Особенности Debian/Ubuntu и RHEL-подобных систем

Различия между системами чаще всего связаны с пакетами, репозиториями debug symbols, политиками хранения и включенным MAC-механизмом. На Ubuntu и Debian чаще встречается AppArmor. Fedora и RHEL используют SELinux как основной механизм обязательного контроля доступа.

command -v apt
command -v dnf
command -v yum
cat /sys/module/apparmor/parameters/enabled 2>/dev/null
cat /sys/fs/selinux/enforced 2>/dev/null

Не отключайте AppArmor или SELinux как постоянное исправление. Сначала найдите запись отказа, проверьте контекст, профиль и путь к ресурсу. AppArmor ограничивает доступ по профилю программы к файлам, capabilities и сетевым ресурсам. SELinux проверяет контексты и политики. Отказ политики обычно сопровождается сообщением в журнале, а не случайным повреждением стека.

Поиск нужного события через coredumpctl

Список доступных дампов

Команда coredumpctl list показывает зарегистрированные события. Ограничивайте поиск временем и исполняемым файлом, чтобы не смешать несколько аварий.

coredumpctl list --since "2026-08-28 10:00:00" --until "2026-08-28 11:00:00"
coredumpctl list /usr/local/bin/my-service
coredumpctl list --pid 12345
coredumpctl list --uid 1001

В таблице вывода зафиксируйте дату, PID, UID, сигнал, значение COREFILE и имя исполняемого файла. PID может повторно использоваться, поэтому связывайте событие с timestamp, командной строкой и журналом unit-файла.

Подробные метаданные события

Для выбранного PID получите подробную запись:

PID=12345
coredumpctl info "$PID" --no-pager
journalctl _PID="$PID" --since "2026-08-28 10:00:00" --until "2026-08-28 10:05:00" --no-pager

В метаданных ищите сигнал, командную строку, рабочий каталог, UID, путь к executable, Build ID, размер дампа, время аварии и сведения о ядре. Сопоставьте их с journalctl -u SERVICE. Если сервис автоматически перезапускается, журнал может содержать несколько PID за короткий интервал.

Как понять, что дамп неполный или отсутствует

Поле COREFILE может показывать, что файл доступен, отсутствует, недоступен или усечен. Причинами служат LimitCORE=0, ограничения ProcessSizeMax и ExternalSizeMax, нехватка места, очистка старых дампов, отключенный обработчик и завершение через SIGKILL.

coredumpctl info "$PID" | sed -n '/COREFILE/,$p'
df -hT
journalctl -k --since "2026-08-28 10:00:00" --no-pager

Если есть только метаданные, можно установить время, PID, сигнал и путь к программе. Нельзя получить достоверный стек вызовов без содержимого core dump либо другого диагностического источника.

Извлечение исполняемого файла и core dump для анализа

Сохранение дампа в отдельный каталог

Создайте закрытый каталог с ограниченным доступом. Не сохраняйте core dump в каталог веб-сервера, общий каталог пользователей или случайную временную директорию.

sudo install -d -m 0700 -o root -g root /var/tmp/core-investigation
sudo sh -c 'df -hT /var/tmp/core-investigation'
PID=12345
sudo coredumpctl dump "$PID" -o /var/tmp/core-investigation/core.my-service.12345
sudo chmod 0600 /var/tmp/core-investigation/core.my-service.12345
sudo sha256sum /var/tmp/core-investigation/core.my-service.12345

Сначала проверьте свободное место, затем копируйте дамп. Команда с -o создает отдельный файл и не требует ручного поиска пути во внутреннем хранилище. Исходную запись не удаляйте до проверки копии.

Проверка соответствия бинарного файла

GDB должен открывать тот исполняемый файл, который работал в момент падения. После обновления пакета путь может остаться прежним, а код и Build ID изменятся.

EXEC=/usr/local/bin/my-service
file "$EXEC"
sha256sum "$EXEC"
readelf -n "$EXEC" | grep -i 'Build ID'
coredumpctl info "$PID" | grep -E 'Executable|Build ID|Package'

Если бинарный файл заменили, найдите пакет или артефакт релиза соответствующей версии. Для системных пакетов используйте сохраненный пакет из репозитория организации или копию, которая была развернута в момент сбоя. Debug symbols должны соответствовать той же версии и Build ID.

Что сохранить вместе с дампом

• Вывод coredumpctl info.
• Журнал unit-файла и сообщения ядра.
• Содержимое unit-файла и эффективные параметры systemd.
• Версию ОС, ядра, приложения и пакетов.
• Путь к бинарному файлу, Build ID и контрольную сумму.
• Сведения о debug symbols.
• Временную шкалу: обновление, изменение конфигурации, рост нагрузки, перезапуск и падение.

Для анализа инфраструктурного контекста пригодятся команды из руководства по мониторингу производительности Linux-сервера. Журнал веб-сервиса полезно сопоставлять с access- и error-логами, для этого подойдет практический разбор логов Nginx и Apache.

Как анализировать core dump в Linux через GDB

Открытие дампа и базовая проверка

Запустите GDB с корректным бинарным файлом и сохраненным core dump:

gdb -q /path/to/executable /var/tmp/core-investigation/core.my-service.12345

Внутри GDB выполните безопасный набор команд чтения:

set pagination off
set confirm off
info files
info proc
bt
thread apply all bt

info files помогает проверить загруженные объекты и символы. bt показывает стек текущего потока. thread apply all bt выводит стеки всех потоков и часто позволяет увидеть поток, который удерживал ресурс или вызвал аварийный путь.

Команды GDB для расширенного backtrace

thread apply all bt full
frame 0
info locals
info args
list
info registers
x/i $pc

bt full добавляет локальные переменные и аргументы, если они доступны. frame 0 выбирает текущий кадр. info registers и x/i $pc помогают связать адрес счетчика команд с инструкцией процессора.

Эти команды читают сохраненное состояние. Они не запускают приложение и не продолжают выполнение процесса. Не вызывайте функции из GDB на production-дампе, если не понимаете последствия.

Зачем нужны debug symbols

Без отладочных символов стек может содержать адреса и обозначения ?? вместо функций и исходных строк. Проверка начинается с бинарного файла:

file /path/to/executable
readelf -n /path/to/executable | grep -i 'Build ID'

Для анализа нужны symbols именно от версии, которая создала дамп. Оптимизация компилятора, inline-функции, повреждение памяти и усеченный core могут оставить пробелы даже при наличии symbols. Механизм debuginfod может автоматически получать символы, поэтому перед запуском GDB проверьте сетевую политику и требования к конфиденциальности среды.

Как интерпретировать SIGSEGV, SIGABRT и другие сигналы

• SIGSEGV: обращение к недопустимому адресу. Ищите первый кадр приложения и проверяйте аргументы, локальные переменные и цепочку вызовов.
• SIGABRT: вызов abort(), assert, авария рантайма или контролируемое завершение после критической ошибки.
• SIGBUS: ошибка доступа к отображенной памяти, выравниванию или устройству.
• SIGFPE: арифметическая ошибка, например деление на ноль.
• SIGKILL: принудительное завершение. Проверьте OOM killer, cgroup, systemd и внешний оркестратор.
• SIGTERM: штатный запрос завершения от systemd или другого управляющего процесса. Сам по себе этот сигнал не доказывает падение приложения.

Как отличить ошибку приложения от внешнего ограничения

Нехватка памяти и работа OOM killer

OOM killer часто завершает процесс через SIGKILL, поэтому core dump отсутствует. Ищите сообщения ядра рядом со временем аварии.

journalctl -k --since "30 min ago" --no-pager | grep -iE 'oom|out of memory|killed process'
free -h
swapon --show

Для сервиса в cgroup проверьте ограничения и счетчики:

systemctl show "$SERVICE" -p ControlGroup -p MemoryMax -p MemoryHigh -p OOMPolicy
CGROUP=$(systemctl show "$SERVICE" -p ControlGroup --value)
cat "/sys/fs/cgroup${CGROUP}/memory.current" 2>/dev/null
cat "/sys/fs/cgroup${CGROUP}/memory.events" 2>/dev/null

Если oom_kill увеличился, а журнал ядра содержит запись о завершении процесса, сначала устраняйте дефицит памяти или завышенное потребление. Backtrace от другого падения не объясняет OOM-инцидент.

Права доступа и ошибки файловой системы

Отказ в доступе обычно проявляется сообщением приложения, кодом EACCES или EPERM. Он может привести к корректному завершению с ошибкой, assert или аварийному пути в плохо обработанном коде.

namei -l /path/to/file
stat /path/to/file
getfacl -p /path/to/file
df -hT
df -ih
findmnt -T /path/to/file

Проверяйте владельца, режимы, ACL, read-only mount, заполнение блоков и inode. df -h показывает свободное место, а df -ih помогает найти исчерпание inode. Для узкого воспроизведения на staging можно применить strace, но не запускайте длительное трассирование на загруженном production-сервисе без оценки накладных расходов и риска раскрытия аргументов.

AppArmor и SELinux

AppArmor использует path-based profiles. Профиль задает, к каким файлам, capabilities и сетевым ресурсам может обращаться программа. При попытке доступа к запрещенному ресурсу ядро блокирует операцию.

cat /sys/module/apparmor/parameters/enabled 2>/dev/null
journalctl -k --since "30 min ago" --no-pager | grep -i 'apparmor.*denied'

Для SELinux:

cat /sys/fs/selinux/enforced 2>/dev/null
journalctl --since "30 min ago" --no-pager | grep -iE 'avc:|selinux'

Сопоставьте время отказа с журналом сервиса и путем к ресурсу. Исправление должно менять профиль или контекст ровно настолько, насколько требует рабочая операция. Отключение защиты скрывает причину и увеличивает область риска.

Лимиты systemd и cgroup

systemctl show "$SERVICE" \
  -p LimitNOFILE -p LimitNPROC -p LimitCORE \
  -p MemoryMax -p MemoryHigh -p TasksMax \
  -p CPUQuota -p RuntimeMaxSec -p OOMPolicy

LimitNOFILE ограничивает открытые файловые дескрипторы, LimitNPROC связан с числом процессов и потоков, TasksMax ограничивает задачи в cgroup, MemoryMax задает предел памяти, а RuntimeMaxSec завершает unit после заданного времени. Сопоставляйте лимит с сообщением приложения и счетчиками cgroup. Само наличие лимита не доказывает, что он сработал.

Признаки ошибки самого приложения

Гипотеза о дефекте приложения сильнее, когда повторяются один сигнал, один участок backtrace и одна последовательность входных данных. Подтверждение усиливают assert, abort(), сообщение о некорректном входе и отсутствие признаков OOM или отказа политики.

Некорректный ввод может привести к аварийному пути. Приложение должно обработать ошибку и вернуть контролируемый результат. Если обработчик вызывает abort при входных данных клиента, гостевой системы или внешнего API, это дефект устойчивости, даже если исходный ввод ошибочен.

Безопасное хранение и очистка core dump

Какие данные могут попасть в дамп

Core dump содержит снимок памяти процесса. В нем могут оказаться пароли, токены, TLS-материалы, ключи, переменные окружения, фрагменты запросов, пользовательские данные и содержимое буферов. Обращайтесь с дампом как с чувствительным артефактом.

Модель угроз включает случайный доступ локального пользователя, раскрытие через общий каталог, передачу разработчику без шифрования, сохранение после окончания расследования и заполнение диска большими файлами. Политика должна определить владельца, группу, срок хранения, место, шифрование при передаче и порядок удаления.

Сравнение способов передачи секретов сервису

Секреты могут попасть в память процесса независимо от способа передачи. Таблица помогает выбрать источник секрета и снизить его видимость в unit-файле, журнале и командной строке.

Матрица доступа для практической схемы

Для рабочей схемы заранее назначьте владельца каждого секрета и диагностического артефакта. Это снижает риск, когда дамп копируют в каталог с более широкими правами, чем исходный сервис.

Ограничение доступа и передача на анализ

sudo install -d -m 0700 -o root -g root /var/tmp/core-investigation
sudo find /var/tmp/core-investigation -maxdepth 1 -type f -printf '%M %u %g %s %p\n'

Не отправляйте дампы в открытые чаты и внешние сервисы без согласования. Перед передачей разработчикам проверьте, требуется ли полный дамп. Для первичного анализа часто хватает coredumpctl info, журнала и обезличенного backtrace. Если нужен файл, передайте его по защищенному каналу с шифрованием и зафиксируйте получателей.

Срок хранения и автоматическая очистка

Определите срок хранения по типу среды и критичности инцидента. Для production-дампов обычно нужен отдельный срок, связанный с расследованием, требованиями безопасности и резервным копированием. Настройки MaxUse и KeepFree ограничивают объем и защищают файловую систему от полного заполнения.

coredumpctl list
sudo coredumpctl purge

Команда purge удаляет доступные дампы. Перед запуском проверьте политику хранения, наличие копии и открытые расследования. Удаление должно быть документированным: укажите идентификатор события, дату, ответственного и причину удаления.

Практический сценарий: от падения сервиса до подтвержденной причины

Фиксация инцидента и сбор контекста

Предположим, сервис worker.service перезапускается после обработки задания. Сначала зафиксируйте его состояние и журнал.

SERVICE=worker.service
SINCE="2026-08-28 10:00:00"
UNTIL="2026-08-28 10:10:00"
systemctl status "$SERVICE" --no-pager
systemctl show "$SERVICE" -p MainPID -p ExecMainCode -p ExecMainStatus -p Result
journalctl -u "$SERVICE" --since "$SINCE" --until "$UNTIL" --no-pager
journalctl -k --since "$SINCE" --until "$UNTIL" --no-pager

Отметьте обновления пакетов, изменения конфигурации, рост нагрузки, смену профиля AppArmor или контекста SELinux, нехватку места и ручные операции администратора.

Поиск дампа и анализ стека

coredumpctl list --since "$SINCE" --until "$UNTIL"
coredumpctl info 12345 --no-pager
sudo coredumpctl dump 12345 -o /var/tmp/core-investigation/worker.12345
mkdir -p /var/tmp/worker-gdb
printf 'set pagination off\ninfo files\nbt full\nthread apply all bt full\n' > /var/tmp/worker-gdb/commands.gdb
gdb -q -batch -x /var/tmp/worker-gdb/commands.gdb /path/to/worker /var/tmp/core-investigation/worker.12345

В отчете выделите кадр приложения, библиотеку, системный вызов и поток, в котором зафиксирован сигнал. Затем проверьте Build ID, чтобы исключить анализ другой версии бинарного файла.

Проверка альтернативных причин

Для SIGKILL сначала проверьте OOM и лимиты памяти. Для SIGSEGV и SIGABRT изучите backtrace, но параллельно проверьте права, политики доступа и изменения конфигурации. Для ошибки открытия файла сопоставьте путь с namei, ACL, mount point и сообщениями AppArmor или SELinux.

Фиксируйте не только подтвержденные гипотезы, но и исключенные. Запись «OOM не подтвержден, в журнале ядра нет сообщений, счетчик cgroup не изменился» полезнее общего вывода «память проверена».

Формулировка первопричины и исправление

Хороший итог выглядит конкретно: сервис получил некорректный вход, вызвал аварийный путь в функции обработки, завершился через SIGABRT, backtrace совпал в трех событиях, OOM и ограничения systemd не подтверждены. Исправление: обновить пакет до версии с обработкой входа и проверить повторным тестом на staging.

После изменения выполните контролируемый запуск, проверьте журнал, статус unit-файла и отсутствие нового события в заданном временном окне. Для облачного staging-сервера можно использовать облачную инфраструктуру Timeweb Cloud, если среда должна быть отделена от production.

Типовые ошибки при работе с coredumpctl и GDB

Диагностика типовых проблем

Перед изменением лимитов, политик или хранения свяжите симптом с проверкой и ожидаемым результатом. Таблица рассчитана на первичный разбор инцидента.

Почему одного journalctl недостаточно

Журнал показывает время события, сигнал, сообщения приложения и systemd. Он может не содержать стек, локальные переменные и состояние памяти. Используйте journalctl как временной контекст для coredumpctl и GDB.

Почему нельзя сразу отключать защитные механизмы

Отключение SELinux или AppArmor может убрать сообщение об отказе ценой ослабления защиты и маскировки неправильной конфигурации. Сначала найдите путь, контекст, профиль и конкретное правило. Временный тест проводите на staging или с узким изменением, которое затем можно удалить.

Почему backtrace может вводить в заблуждение

Стек бывает неполным из-за оптимизаций, отсутствующих symbols, повреждения памяти, inline-функций, несовпадающих библиотек и усеченного core dump. Проверяйте версии всех ключевых shared libraries и повторяйте анализ с symbols от того же пакета.

Не запускайте GDB из каталога приложения, если там хранятся конфигурации и секреты. Команды расследования, временные файлы и журналы складывайте в отдельный закрытый каталог.

Чек-лист диагностики падения Linux-сервиса

Минимальный набор команд

SERVICE=my-service.service
PID=12345

systemctl status "$SERVICE" --no-pager
systemctl show "$SERVICE" -p MainPID -p ExecMainCode -p ExecMainStatus -p Result
journalctl -u "$SERVICE" --since "30 min ago" --no-pager
journalctl -k --since "30 min ago" --no-pager
coredumpctl list --since "30 min ago"
coredumpctl info "$PID" --no-pager
sudo coredumpctl dump "$PID" -o /var/tmp/core-investigation/core."$PID"
gdb -q /path/to/executable /var/tmp/core-investigation/core."$PID"

• systemctl status подтверждает состояние unit-файла и последний результат запуска.
• journalctl -u показывает контекст конкретного сервиса.
• journalctl -k помогает найти OOM, ошибки ядра и отказы MAC-политик.
• coredumpctl list подтверждает наличие события.
• coredumpctl info связывает PID, сигнал, executable и Build ID.
• coredumpctl dump сохраняет копию для повторного анализа.
• GDB показывает состояние потоков, стеков, регистров и доступных локальных данных.

Что должно быть в отчете об инциденте

• Имя сервиса, hostname или идентификатор среды и точное время сбоя.
• PID, сигнал, код завершения, Build ID и версия пакета.
• Вывод coredumpctl info и путь к защищенной копии дампа.
• Backtrace текущего потока и всех потоков, желательно с debug symbols.
• Системные сообщения о памяти, диске, правах, AppArmor или SELinux.
• Эффективные лимиты systemd и cgroup.
• Проверенные гипотезы и основания для их подтверждения или исключения.
• Исправление, контрольный тест, повторный запуск и наблюдение после изменения.
• Владелец артефактов и срок удаления core dump.

Для регулярных расследований храните шаблон отчета в базе знаний с версией команд и проверкой актуальности. Подход к структуре таких материалов разобран в руководстве по созданию базы знаний для IT-специалистов.

Главное правило диагностики: сначала сохраните факты, затем извлеките дамп, проверьте соответствие бинарного файла, получите backtrace и только после этого меняйте лимиты, политики или код. Такой порядок сохраняет доказательства и сокращает риск исправить не ту причину.