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

Hardware Error / EDAC: ошибки памяти в журнале

Ошибки памяти делятся на исправленные и неисправленные. Исправленные не приводят к сбою сразу, но их рост — предвестник отказа. Неисправленные обычно означают падение процесса или всей машины. Разбирать падения служб без взгляда на эти сообщения — трата времени.

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

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

Растёт число исправленных ошибок

Ядро исправляет ошибку и продолжает работу. Рост счётчика указывает на деградацию модуля памяти.
Неисправленная ошибка убила процесс

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

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

Диагностика

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

Аппаратные сообщения о памяти.

journalctl -k --no-pager | grep -iE "EDAC|Hardware Error|mce:" | tail -20

Сводка ошибок памяти по контроллерам, если средство установлено.

sudo ras-mc-ctl --summary 2>/dev/null

Сколько всего падений с нарушением доступа.

journalctl -k --no-pager | grep -c segfault

Решение

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

1. Растёт число исправленных ошибок

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

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

Посмотрите счётчики ошибок памяти.

journalctl -k --no-pager | grep -iE "EDAC|Corrected error" | tail
sudo ras-mc-ctl --summary 2>/dev/null | head

Как исправить: Запланируйте замену модуля. Точное место обычно названо в сообщении: контроллер, канал и слот.

2. Неисправленная ошибка убила процесс

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

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

Посмотрите сообщения об аппаратной ошибке и падения служб рядом по времени.

journalctl -k -b --no-pager | grep -iE "Hardware Error|mce:|Uncorrected" | tail

Как исправить: Замените модуль памяти. До замены падения служб будут повторяться в непредсказуемых местах.

3. Падения служб списывают на программу

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

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

Сопоставьте падения с аппаратными сообщениями.

journalctl -b --no-pager | grep -iE 'segfault|Hardware Error' | tail -20

Как исправить: Проверьте память отдельным средством. Общий признак аппаратной причины — разнообразие падающих программ.

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

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

kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_MC#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x1a2b3c offset:0x40 grain:32 syndrome:0x0)
kernel: mce: [Hardware Error]: Machine check events logged

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

segfault at ... in журнале: процесс службы упал по нарушению доступа Ядро записало нарушение доступа к памяти. Как прочитать строку, собрать дамп и отделить дефект программы от неисправной памяти.
signal=SEGV (status=11/SEGV) в systemd Процесс службы завершён сигналом SEGV: обращение к недопустимой памяти. Как собрать дамп и что смотреть.
task blocked for more than 120 seconds Ядро сообщает о процессе, зависшем в ожидании ввода-вывода дольше двух минут. Служба при этом не отвечает и не убивается.
Cannot allocate memory в журнале службы Не удалось выделить память: предел службы, память машины, настройка overcommit, исчерпанные области отображения.
Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
Elasticsearch: служба падает из-за размера кучи JVM Размер кучи больше доступной памяти или больше предела службы: падение при старте или под нагрузкой.
Failed with result 'oom-kill' Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Function not implemented в контейнере Ошибка 38 при системном вызове: вызов запрещён фильтром или отсутствует в окружении. Разбор для контейнеров.

Источники

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