Как узнать, что вызывает systemd-coredump?

Вопрос или проблема

dec 29 19:43:31 mashenka kernel: git-remote-http[30150]: segfault at 18 ip 0000576c7321949f sp 00007ffd619e7920 error 4 in git-remote-http[b049f,576c7316d000+d5000] likely on CPU 2 (core 2, socket 0)
dec 29 19:43:31 mashenka kernel: Code: 44 89 e6 4c 89 ef e8 c0 2a f9 ff c5 fa 7e 04 24 85 c0 0f 84 03 fc ff ff e9 eb fd ff ff 66 0f 1f 44 00 00 48 8b 15 f9 5e 05 00 <48> 39 5a 18 0f 84 07 01 00 00 c4 e1 f9 7e c7 44 89 e6 c5 f9 d6 04
dec 29 19:43:31 mashenka systemd-coredump[30151]: Process 30150 (git-remote-http) of user 1000 terminated abnormally with signal 11/SEGV, processing...
dec 29 19:43:31 mashenka systemd[1]: Started Process Core Dump (PID 30151/UID 0).
dec 29 19:43:31 mashenka systemd-coredump[30152]: [🡕] Process 30150 (git-remote-http) of user 1000 dumped core.

                                                  Stack trace of thread 30150:
                                                  #0  0x0000576c7321949f n/a (n/a + 0x0)
                                                  ELF object binary architecture: AMD x86-64
dec 29 19:43:31 mashenka systemd[1]: [email protected]: Deactivated successfully.

Ответ или решение

Как выявить причину сбоя systemd-coredump?

При наблюдении частых ошибок в системных логах, таких как системные дампы памяти с использованием systemd-coredump, важно понять, что происходит с вашей системой. В представленной проблеме часто вызывает сбои процесс git-remote-http, что является индикатором нештатного поведения. Ниже приводится детальное пошаговое руководство по выяснению причины и устранению проблемы.

Фаза: Форензика

На первом этапе важно собрать как можно больше информации о сбое. Убедитесь, что вы понимаете, какой именно процесс и какие пользователи вовлечены, а также частоту возникновения сбоя.

• Журналы и сообщения: Используйте journalctl -f или journalctl -xe для просмотра последних логов. Вы уже получили информацию, что процесс git-remote-http вызвал сегментацию (segfault), что часто указывает на проблемное обращение к памяти.

• core dumps: Убедитесь, что система сохраняет дампы памяти для дальнейшего анализа. Они обычно хранятся в директории /var/lib/systemd/coredump/. Используйте утилиту coredumpctl для просмотра, например:

  coredumpctl list
  coredumpctl info <PID>
  coredumpctl gdb <PID>

Фаза: Обследование

На следующем шаге необходимо определить, что именно вызывает сбой в git-remote-http.

• GDB анализ: Подключите отладчик GDB к дампу памяти для глубокого анализа:

  gdb /path/to/executable /path/to/core
  # Используйте команды backtrace для анализа стека вызовов:
  (gdb) bt

• Проверка cron задач: Если сбой происходит периодически, проверьте расписание задач cron, используя:

  crontab -l
  less /etc/crontab
  less /etc/cron.d/*

Фаза: Разъяснение

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

• Исходный код и зависимости: Если проблема наблюдается в пользовательской версии git, проверьте код на наличие ошибок управления памятью. Если проблема связана с внешними библиотеками, проверьте версии и зависимости.

• Обновления и конфликты: Убедитесь, что все пакеты обновлены. Иногда проблемы возникают после обновления из-за несовместимости библиотек.

  sudo apt update && sudo apt upgrade

Фаза: Снижение воздействия

Для предотвращения будущих сбоев и защиты системы следует предпринять следующие действия.

• Имитация и тестирование: Воспроизведите условия, которые могли привести к дампу памяти в изолированной среде. Используйте контрольную версию системы или контейнеры для тестов.

• Логи и мониторинг: Настройте продвинутые системы мониторинга и алертирования (например, Nagios или Zabbix), чтобы оперативно реагировать на потенциальные сбои.

Заключение

Выявление проблем, связанных с systemd-coredump, требует тщательного подхода и поэтапного анализа данных. Используя данные из системных логов и дампов памяти, следуя представленным шагам, вы сможете диагностировать и устранить проблему с минимальными издержками.