SystemdDoctor
служба не работает ядро падения память

segfault at ... in журнале: процесс службы упал по нарушению доступа

Строка о нарушении доступа — это запись ядра о том, что процесс обратился к недопустимому адресу и был убит. Для разбора важны три вещи: какая библиотека названа в строке, повторяется ли адрес и есть ли дамп памяти.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Дефект в программе или библиотеке

    Самая частая причина. Названная в строке библиотека указывает, где искать: часто это несовместимость версий после обновления.

  2. Неисправная память

    Повторяющиеся нарушения по разным адресам в разных программах указывают на неисправность памяти, а не на дефект кода.

  3. Дамп памяти не собирается

    Без дампа разбор ограничен одной строкой. Сбор дампов включается отдельно, и на многих системах он выключен или дампы обрезаны.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Строки ядра о нарушениях доступа.

journalctl -k -b --no-pager | grep -i segfault | tail

Собранные дампы памяти.

coredumpctl list --no-pager | tail

Подробности падения: сигнал, стек, версия программы.

coredumpctl info myapp

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Дефект в программе или библиотеке
Почему происходит
Самая частая причина. Названная в строке библиотека указывает, где искать: часто это несовместимость версий после обновления.
Как проверить
Посмотрите строку целиком и версии библиотек. 
journalctl -k -b --no-pager | grep -i segfault | tail -3
ldd /usr/local/bin/myapp | head
Как исправить
Обновите программу и библиотеки до совместимых версий. Дамп памяти даст разработчикам точное место сбоя. 
coredumpctl info myapp
2. Неисправная память
Почему происходит
Повторяющиеся нарушения по разным адресам в разных программах указывают на неисправность памяти, а не на дефект кода.
Как проверить
Посмотрите ошибки памяти и разнообразие падений. 
journalctl -k -b --no-pager | grep -iE "EDAC|Hardware Error|mce" | tail
journalctl -k --no-pager | grep -c segfault
Как исправить
Проверьте память отдельным средством. Падения разных программ в разных местах — сильный признак неисправного модуля.
3. Дамп памяти не собирается
Почему происходит
Без дампа разбор ограничен одной строкой. Сбор дампов включается отдельно, и на многих системах он выключен или дампы обрезаны.
Как проверить
Посмотрите состояние сбора дампов. 
coredumpctl list --no-pager 2>/dev/null | tail -5
systemctl show myapp.service -p LimitCORE
Как исправить
Включите сбор дампов и снимите ограничение на их размер для нужной службы. Дампы содержат память процесса: хранить их на боевой машине долго не стоит. 
[Service]
LimitCORE=infinity

Пример вывода

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

kernel: myapp[1200]: segfault at 18 ip 00007f3a2c1b4e21 sp 00007ffd8a3c2b90 error 4 in libssl.so.3[7f3a2c180000+8b000]
kernel: Code: 48 8b 47 10 48 85 c0 74 0d ...
systemd[1]: myapp.service: Main process exited, code=dumped, status=11/SEGV

Связанные ошибки

Источники

  • coredumpctl(1)
    Работа с собранными дампами памяти.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено программой с обращением по нулевому указателю.     собственная проверка, systemd 255
    сверено 15 сентября 2026