signal=SEGV (status=11/SEGV) в systemd — причины и решение

Что это значит

Практически полезная часть разбора — найти, что именно упало. При включённом systemd-coredump дамп попадает в журнал вместе с трассировкой стека, и это отвечает на вопрос быстрее любых догадок.

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

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

Дефект в программе или её расширении

Чаще всего падает не сама служба, а подключаемый модуль: расширение php-fpm, модуль nginx, библиотека в сборке. Особенно после обновления одной части системы без другой.
Несовместимость версий библиотек после обновления

Программа собрана под одну версию библиотеки, а в системе стоит другая. Символы совпали по имени, но не по устройству — и программа падает при первом обращении.
Повреждённая память или переполнение стека

Глубокая рекурсия и очень маленький предел стека дают тот же сигнал. Аппаратные проблемы памяти проявляются реже, но выглядят так же.

Диагностика

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

Список сохранённых дампов: сразу видно, падала ли служба раньше и как часто.

coredumpctl list --no-pager | tail -10

Трассировка стека последнего падения — главный источник правды о причине SEGV.

coredumpctl info myapp | head -40

Result будет core-dump или signal, а счётчик перезапусков покажет, единичный это случай или цикл.

systemctl show myapp.service -p Result -p NRestarts

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

journalctl -u myapp.service -n 30 --no-pager

Решение

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

1. Дефект в программе или её расширении

Почему происходит: Чаще всего падает не сама служба, а подключаемый модуль: расширение php-fpm, модуль nginx, библиотека в сборке. Особенно после обновления одной части системы без другой.

Как проверить

Посмотрите дамп и трассировку: там видно, в какой библиотеке случилось падение.

coredumpctl list --no-pager | tail -5
coredumpctl info | head -40

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

2. Несовместимость версий библиотек после обновления

Почему происходит: Программа собрана под одну версию библиотеки, а в системе стоит другая. Символы совпали по имени, но не по устройству — и программа падает при первом обращении.

Как проверить

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

ldd /usr/local/bin/myapp | head -20
grep -iE "upgrade|install" /var/log/dpkg.log | tail -10

Как исправить: Пересоберите или переустановите программу под текущие библиотеки. При ручной установке в /usr/local это делается вручную: пакетный менеджер о таких файлах не знает.

3. Повреждённая память или переполнение стека

Почему происходит: Глубокая рекурсия и очень маленький предел стека дают тот же сигнал. Аппаратные проблемы памяти проявляются реже, но выглядят так же.

Как проверить

Посмотрите предел стека у службы и записи ядра об ошибках памяти.

systemctl show myapp.service -p LimitSTACK
journalctl -k -b --no-pager | grep -iE "mce|edac|hardware error"

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

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

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

× myapp.service - My application
     Active: failed (Result: core-dump) since Mon 2026-09-15 14:30:11 MSK; 20s ago
   Main PID: 13900 (code=dumped, signal=SEGV)

systemd[1]: myapp.service: Main process exited, code=dumped, status=11/SEGV
systemd-coredump[13905]: Process 13900 (myapp) of user 995 dumped core.
                         Stack trace of thread 13900:
                         #0  0x00007f2a1c4b21a0 handler (libmyext.so.2 + 0x121a0)
systemd[1]: myapp.service: Failed with result 'core-dump'.

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

Failed with result 'core-dump' Состояние core-dump: процесс службы аварийно завершился и сохранил дамп памяти. Как открыть дамп и прочитать трассировку.
signal=ABRT (status=6/ABRT) в systemd Процесс службы завершён сигналом ABRT: программа сама прервала работу после внутренней проверки. Где искать причину.
signal=BUS (status=7/BUS) в systemd Процесс службы завершён сигналом BUS: ошибка доступа к памяти, часто из-за усечённого файла в отображении или заполненного диска.
signal=FPE (status=8/FPE) в systemd Процесс службы завершён сигналом FPE: арифметическая ошибка, чаще всего деление на ноль в целочисленной арифметике.
signal=ILL (status=4/ILL) в systemd Процесс службы завершён сигналом ILL: недопустимая инструкция процессора. Обычно сборка не под этот процессор.
signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.

Где встречается чаще всего

Источники

coredumpctl(1)
Просмотр сохранённых дампов и трассировок. официальная документация, systemd 255
сверено 15 сентября 2026
systemd-coredump(8)
Сохранение дампов памяти и их место в журнале. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено намеренным падением тестовой программы; дамп и трассировка получены через coredumpctl. собственная проверка, systemd 255
сверено 15 сентября 2026