Что делать, если зависший процесс в состоянии D не завершается SIGKILL?

SIGKILL нельзя перехватить, заблокировать или проигнорировать в пользовательском коде, однако для задачи в непрерываемом ожидании это не гарантирует немедленного завершения. Сигнал может ожидать, пока задача выйдет из пути ядра, в котором находится. Поведение также различается для обычного непрерываемого ожидания и ожидания, допускающего фатальный сигнал. До любых дальнейших действий соберите данные: PID, полную команду, владельца, PPID, время запуска, состояние STAT, значение wchan, cgroup, сведения об открытых ресурсах, время начала симптома и данные подсистемы, с которой связан процесс. Состояние D часто связано с I/O, но само по себе не доказывает проблему диска. Для расследования может потребоваться отдельная диагностика файловой системы, RAID, SAN/NAS или сети. Не перезагружайте сервер только для удаления PID, пока не оценены последствия для данных, сервисов и доступа к серверу.

Можно ли сразу убить процесс в Linux через SIGKILL?

Нет, SIGKILL не должен быть первой реакцией. Сначала повторно подтвердите PID, команду, владельца, PPID и время запуска, затем убедитесь, что процесс не управляется systemd. Самостоятельному процессу сначала отправляют SIGTERM, ждут приемлемое для приложения время и проверяют результат. SIGKILL применяют только в крайнем случае.

Можно ли убить zombie process в Linux обычным сигналом?

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

Связана ли ошибка Too many open files с высокой загрузкой CPU?

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

Почему ulimit -n не показывает лимит уже работающей службы?

Потому что ulimit -n показывает лимиты только текущей оболочки и её будущих потомков. Для уже работающего процесса или службы из другого сеанса он не подходит. Фактические мягкий и жёсткий лимиты конкретного PID проверяют в /proc/ /limits; для systemd-службы учитывают LimitNOFILE= и применённую конфигурацию unit.

Можно ли заменить systemctl stop командой systemctl kill?

Нет, для обычной управляемой остановки службы предпочтителен systemctl stop. Команда systemctl kill только отправляет сигнал процессам unit и не выполняет полный жизненный цикл остановки. Её область действия и результат зависят от параметров команды, версии systemd и конфигурации unit.

Процессы, CPU и нагрузка Linux: диагностика высокой загрузки

При высокой нагрузке не останавливайте процессы сразу: сначала сохраните снимок uptime, top или htop, ps и, при наличии, pidstat. Сопоставьте Load average, категории CPU, состояние задач, память, владельца, родительский процесс и принадлежность к службе. Управляемую системную службу обычно останавливают или перезапускают через systemctl; самостоятельному процессу сначала посылают SIGTERM, затем проверяют, что завершился именно нужный экземпляр, и только в крайнем случае используют SIGKILL.

До сбора данных не перезапускайте службу и не отправляйте SIGKILL

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

Первичный снимок: что собрать при высокой нагрузке

Высокая нагрузка CPU Linux, зависание процесса и медленная работа сервера имеют разные причины. Начните с текущей картины, а не с одного показателя. Утилиты htop, pidstat, iostat и lsof могут отсутствовать в минимальной установке: htop обычно поставляется одноимённым пакетом, pidstat и iostat — пакетом sysstat, lsof — одноимённым пакетом. Названия пакетов, репозитории и способ установки различаются между дистрибутивами; устанавливайте их по правилам целевой ОС, например через APT в Ubuntu и Debian или DNF и YUM.

Соберите данные до воздействия на процесс

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

1
Зафиксируйте время и общую нагрузку
Запишите время наблюдения и вывод uptime. Он показывает значения load average за 1, 5 и 15 минут и число вошедших пользователей.
2
Посмотрите CPU, память и задачи
Запустите top; при наличии htop используйте его как интерактивное представление процессов. Зафиксируйте верхнюю строку нагрузки, сводку CPU, число задач по состояниям и строки проблемных процессов.
3
Получите сортируемый список процессов
Выведите PID, PPID, владельца, состояние, время запуска, CPU, память и команду через ps. Это помогает сохранить данные и сопоставить процесс с родителем или службой.
4
Проверьте динамику при наличии pidstat
Если доступен pidstat, снимите несколько интервалов. Один короткий пик CPU не равен постоянной перегрузке; динамический вывод позволяет увидеть повторяющиеся процессы и потоки.

Показывает текущий момент, время работы и load average за 1, 5 и 15 минут.

uptime

Интерактивно показывает задачи и сводку CPU. В типичном `top` клавиша `P` сортирует по CPU, а `M` — по памяти; доступные поля и клавиши зависят от версии procps-ng и настроек пользователя.

top

Выводит список процессов, их [PID](/baza-znaniy/glossariy/process-identifier), PPID, владельца, время старта, состояние, долю CPU и памяти и команду; сортировка — по убыванию CPU. Двойной параметр `w` запрашивает вывод без ограничения шириной терминала. При сохранении результата учитывайте, что в аргументах команд могут находиться чувствительные данные.

ps -ww -eo pid,ppid,user,lstart,stat,%cpu,%mem,cmd --sort=-%cpu

Если установлена утилита `pidstat` из sysstat, показывает для процессов CPU, память и ввод-вывод с интервалом в одну секунду пять раз. Доступность полей зависит от версии и ядра.

pidstat -u -r -d -p ALL 1 5

Что означают проценты в top и ps

Набор полей и формат зависят от версии procps-ng, параметров запуска и настроек экрана. В top строка %Cpu(s) обычно делит учтённое время CPU на user, system, nice, idle, iowait, irq, softirq, steal и другие категории. В ps поле %CPU — расчётная доля времени CPU, а не мгновенная аппаратная загрузка. Сравнивайте несколько наблюдений, а не одну строку.

Высокий load average при невысоком CPU

Load average — экспоненциально сглаженное среднее числа задач, которые выполняются или готовы выполняться на CPU, а также задач в непрерываемом ожидании. Три числа в uptime и top имеют горизонты сглаживания 1, 5 и 15 минут. Это не арифметические средние по трём конечным окнам: более старые наблюдения постепенно теряют вес. Короткое значение быстрее реагирует на изменение, длинное показывает устойчивую тенденцию. Load average — не процент CPU и не число «занятых ядер».

Как читать изменение load average

Наблюдение	Что может означать	Что проверить
1 минута заметно выше 5 и 15 минут	Недавний или продолжающийся всплеск очереди задач	Процессы с CPU, состояние `R`, задания по расписанию, начало интенсивного I/O
1, 5 и 15 минут высоки и близки	Длительная очередь выполнения или ожидания	Динамику CPU, задачи `D`, ограничения cgroup, хранение и прикладную нагрузку
15 минут выше 5 и 1 минуты	Нагрузка могла уменьшиться, но сглаженное среднее ещё отражает прошлый период	Текущий `top`, недавние изменения и историю мониторинга
Load высокий, idle CPU остаётся заметным	В очереди могут быть задачи в непрерываемом ожидании, либо нагрузка ограничена не всеми CPU	Состояния задач, iowait, доступные CPU и cgroup

Сопоставление load с числом процессоров полезно только в контексте. У виртуальной машины или контейнера может быть ограничен набор доступных CPU, а cgroup может ограничивать CPU quota или affinity. Кроме того, высокий load создают не только готовые к вычислению задачи, но и задачи в непрерываемом ожидании. Поэтому правило «load должен быть ниже числа ядер» не является самостоятельным диагнозом.

CPU-bound или ожидание ввода-вывода: роль iowait

iowait — категория учёта времени CPU: обычно это время, когда конкретный CPU простаивал при наличии незавершённых операций ввода-вывода. Это не счётчик одного процесса, не измерение задержки диска и не доказательство неисправности накопителя. Особенности расчёта зависят от ядра, а на многопроцессорных системах агрегированный процент особенно важно читать вместе с состояниями задач и фактической активностью I/O.

Признак	Вероятная ветка	Проверка до исправления
Высокие `us` или `sy`, процессы стабильно используют CPU, есть `R`	CPU-bound: вычисления в пользовательском коде или ядре	`top`, `ps --sort=-%cpu`, `pidstat -u`; сопоставить команду, владельца и время запуска
Значимый `wa`, много задач `D`, CPU не занят вычислениями	Ожидание I/O или иной путь непрерываемого ожидания	`ps` по состоянию, `pidstat -d`; при наличии — `iostat`; далее проверять соответствующую подсистему
Load высок, iowait низок, CPU тоже не полностью занят	Ожидание может быть не отражено одним iowait; возможны cgroup, блокировки, особенности нагрузки	Состояния задач, доступные CPU, cgroup и метрики приложения

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

ps -eo pid,ppid,user,stat,wchan:32,%cpu,%mem,cmd --sort=stat

Если доступна утилита `iostat` из sysstat, показывает сводку CPU и статистику устройств в трёх интервалах. Это дополнительная проверка активности и задержек, но не полная диагностика RAID, SAN/NAS, файловой системы или сети.

iostat -xz 1 3

Когда переходить к диагностике хранилища

Если наблюдаются задачи D, рост iowait или аномалии метрик устройств, зафиксируйте PID, команды, точки монтирования и время симптома. Дальнейший поиск причин медленного I/O на уровне файловой системы, RAID, SAN/NAS или сети требует отдельной диагностики соответствующей подсистемы.

Как посмотреть процессы Linux и распознать состояние задачи

Процесс имеет PID, владельца, родительский PID и связанные ресурсы. В top, htop и ps сначала найдите строку по CPU, памяти или состоянию, затем уточните полную команду, PPID, время старта и принадлежность к службе. htop удобен деревом процессов и интерактивной сортировкой, но его набор колонок и горячих клавиш настраивается и зависит от версии.

Основные состояния в полях `STAT` утилиты `ps` и `S` утилиты `top`

Состояние	Смысл	Действие
`R`	Выполняется или готова к выполнению	При высоком CPU определить команду, владельца, PPID, длительность и источник запуска
`S`	Прерываемое ожидание, например ожидание события или таймера	Само по себе обычно нормально; оценивать вместе с назначением процесса
`D`	Непрерываемое ожидание в ядре, часто связанное с I/O, но не только с ним	Не ожидать немедленного действия сигналов; собрать `wchan`, ресурсы, стек при наличии утверждённой процедуры и данные подсистемы
`T`	Остановлена заданием управления работой или сигналом SIGSTOP/SIGTSTP	Установить, кто и зачем остановил задачу; при допустимости продолжить SIGCONT либо исправить управляющий сценарий
`Z`	Завершилась, но родитель ещё не прочитал её статус	Не посылать сигналы зомби; найти и диагностировать родительский процесс

Буквы в STAT могут содержать дополнительные модификаторы, а точный вид зависит от ps и версии утилиты. Зомби-процесс не выполняет инструкций и не хранит пользовательское адресное пространство: остаётся только запись, нужная родителю для получения кода завершения. Обычный сигнал зомби не завершит, потому что завершать уже нечего. Если родитель корректно обработает дочерний процесс или завершится и будет переподчинён другому родителю, запись обычно сможет быть обработана; решение о воздействии на родителя требует оценки последствий.

Перед остановкой: идентифицируйте процесс и его владельца

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

Повторно идентифицирует конкретный PID перед действием. Замените `<PID>` фактическим номером; команда не изменяет процесс.

ps -p <PID> -o pid,ppid,user,lstart,stat,%cpu,%mem,args

Показывает cgroup процесса. В systemd-системах путь нередко содержит имя unit, но это не универсальная гарантия: интерпретируйте вывод вместе с `systemctl`.

cat /proc/<PID>/cgroup

Для предполагаемой службы показывает её состояние и обычно часть связанных процессов. Подставьте подтверждённое имя unit, например `example.service`.

systemctl status <unit>

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

systemctl show -p ControlGroup -p MainPID -p KillMode -p KillSignal -p TimeoutStopUSec -p FinalKillSignal <unit>

Как остановить systemd-службу и самостоятельный процесс

Разделяйте две ветки. Если процессом управляет systemd, используйте systemctl, а не ручной kill по PID: менеджер учитывает unit и cgroup его процессов. Если это самостоятельный процесс, применяйте сигнал процесса после повторной идентификации. Полное управление службами описано в статье «systemd и systemctl: управление службами и автозагрузкой Linux», а диагностика не запускающейся службы — в материале о systemd-службах.

Ветка 1: процесс принадлежит systemd-службе

1
Подтвердите unit и оцените последствия
Проверьте systemctl status <unit>, MainPID и cgroup. Установите, можно ли прервать соединения, фоновые задания или административный доступ.
2
Выберите stop или restart
Используйте systemctl stop <unit>, если службу нужно оставить остановленной; systemctl restart <unit> — если нужен новый запуск и это допустимо для приложения. Не применяйте restart только для того, чтобы «проверить, поможет ли».
3
Проверьте результат
Повторите systemctl status <unit>, проверьте нужную прикладную функцию и убедитесь, что старые PID не остались неожиданно активны.

Штатно останавливает unit. Обычно требуются административные права. Поведение определяется unit: в частности, `KillSignal=`, `TimeoutStopSec=`, `KillMode=` и при наличии `FinalKillSignal=` влияют на сигналы, срок ожидания и набор затрагиваемых процессов.

sudo systemctl stop <unit>

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

sudo systemctl restart <unit>

Почему systemctl kill — не замена stop

systemctl kill отправляет сигнал процессам unit, но не выполняет полный жизненный цикл остановки как systemctl stop. Его выбор, область действия и результат зависят от параметров команды, версии systemd и unit. Для обычной управляемой остановки предпочтителен stop; нестандартные случаи сверяйте с документацией systemd и unit.

Ветка 2: самостоятельный процесс

1
Повторно подтвердите идентичность
Снова выполните ps -p <PID> -o pid,ppid,user,lstart,stat,args. Проверьте, что PID не был переиспользован и процесс не оказался частью службы.
2
Отправьте SIGTERM
Используйте kill -TERM <PID>. Стандартное действие SIGTERM — завершение процесса, но приложение может установить обработчик сигнала, проигнорировать или заблокировать его. Обработчик позволяет корректному приложению освободить ресурсы и завершить работу штатно.
3
Подождите и проверьте
Через интервал, приемлемый для конкретного приложения, снова проверьте PID, команду и состояние. Длительность ожидания определяется его операцией и требованиями к простою, а не универсальным числом секунд.
4
Рассмотрите SIGKILL как крайнюю меру
Если процесс точно тот же, не управляется службой и штатно не завершился, допустим kill -KILL <PID>. SIGKILL нельзя перехватить, заблокировать или проигнорировать в пользовательском коде, поэтому приложение не выполнит собственную очистку.

Посылает SIGTERM самостоятельному процессу от текущего пользователя, если есть права. Для чужого процесса обычно нужны административные права.

kill -TERM <PID>

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

kill -KILL <PID>

SIGKILL не всегда даёт немедленный результат для D-задачи

Задача в непрерываемом ожидании может не обработать ожидающий сигнал, пока не выйдет из соответствующего пути ядра Linux. В ядре существуют различия между обычным непрерываемым ожиданием и ожиданием, допускающим фатальный сигнал, поэтому нельзя обещать одинаковое поведение для всех случаев. Зафиксируйте PID, команду, владельца, PPID, время запуска, STAT, wchan, cgroup, открытые ресурсы, время начала симптома и данные подсистемы, с которой связан процесс. Не перезагружайте сервер только ради исчезновения PID без оценки последствий.

SIGSTOP нельзя перехватить, заблокировать или проигнорировать в пользовательском коде, но задача в непрерываемом ожидании может не остановиться немедленно: действие сигнала будет отложено, пока состояние ядра не позволит его применить. SIGCONT продолжает остановленный процесс, если тот может выполняться. Это инструменты управления состоянием, а не лечение нагрузки: остановленный процесс может удерживать блокировки, соединения или ресурсы. Смысл сигналов, ограничения доставки и поведение задач в ожидании следует сверять с man-страницами signal(7), kill(1) и документацией ядра используемого выпуска.

Ошибка Too many open files: проверяйте лимиты отдельно от CPU

Ошибка Too many open files относится к лимитам файловых дескрипторов, а не к загрузке CPU. Она может означать достижение лимита конкретного процесса, лимита пользователя, заданного для сеанса, либо лимита службы. Прежде чем менять настройки, определите, какой процесс получил ошибку, сколько дескрипторов он открыл и какой именно лимит действует.

Источник	Что показывает или задаёт	Важное ограничение
`/proc/<PID>/limits`	Фактические мягкий и жёсткий лимиты уже работающего процесса	Это основной источник для расследования конкретного PID; изменение конфигурации не меняет его прошлое состояние автоматически
`ulimit -n`, `ulimit -Sn`, `ulimit -Hn`	Лимиты текущей оболочки и её будущих потомков	Не показывают лимиты уже работающей службы или процесса из другого сеанса
`/etc/security/limits.conf` и limits.d	Правила PAM limits для пользовательских сеансов при соответствующей PAM-конфигурации	Обычно не являются прямой настройкой systemd system service
`LimitNOFILE=` в unit systemd	RLIMIT_NOFILE для процессов, запускаемых этим unit	Требует учёта drop-in-файлов, версии systemd и перезапуска процесса для применения

Показывает действующие лимиты работающего процесса, включая `Max open files`. Замените `<PID>` и учитывайте права доступа к `/proc`.

cat /proc/<PID>/limits

Встроенная команда текущей оболочки [ulimit](/baza-znaniy/glossariy/ulimit) показывает мягкий и жёсткий лимиты открытых файлов для этой оболочки. Это не проверка лимита уже работающей systemd-службы.

ulimit -Sn; ulimit -Hn

Показывает эффективное свойство LimitNOFILE= для указанного unit, если его предоставляет используемая версия systemd. Для проверки реального процесса сопоставьте результат с `/proc/<PID>/limits`.

systemctl show -p LimitNOFILE <unit>

Приблизительно считает видимые файловые дескрипторы конкретного процесса. Недостаток прав или ограничения монтирования `/proc` могут скрыть содержимое; число не объясняет, какие именно ресурсы удерживаются.

ls /proc/<PID>/fd | wc -l

Если установлен `lsof` и есть нужные права, показывает открытые файлы, сокеты и другие дескрипторы процесса. Используйте для поиска типа ресурса, а не только для подсчёта.

lsof -p <PID>

Не задавайте лимит файловых дескрипторов наугад

Увеличение LimitNOFILE= или пользовательских лимитов может скрыть утечку дескрипторов и повышает потребление ресурсов при росте числа открытых объектов. Подходящее значение зависит от приложения, числа соединений, доступной памяти и конфигурации. Сначала изучите документацию приложения и фактический состав дескрипторов; вопросы выбора лимитов и hardening относятся к кластеру security.

После изменения LimitNOFILE= в unit обычно требуется перечитать определения через systemctl daemon-reload и перезапустить затронутую службу, чтобы новый процесс получил лимит. Это уже изменение конфигурации службы: сохраните исходное состояние и проверьте результат через /proc/<PID>/limits. Порядок работы с unit и риски перезапуска описаны в статье «systemd и systemctl: управление службами и автозагрузкой Linux».

Если причина не локализована

При признаках нехватки RAM, swap или завершений процессов ядром не меняйте параметры подкачки в рамках диагностики CPU: перейдите к статье «Не хватает памяти в Linux: RAM, swap, OOM Killer и настройка подкачки».
Если служба не запускается, перезапускается или находится в failed, сохраните её статус и изучайте причины по статье «Служба systemd не запускается: диагностика ошибок и восстановление».
Для выборки записей по unit и времени симптома используйте материал «Журналы Linux: journalctl, rsyslog и logrotate».
Если зависание связано с блокировкой пакетного менеджера, не завершайте процесс наугад: используйте диагностику блокировок и ошибок APT/DNF.

Термины в статье

Блокировка менеджера пакетов: Блокировка менеджера пакетов — механизм взаимного исключения, сериализующий установку, обновление и удаление пакетов для сохранения согласованности пакетной базы и файлов.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Зомби-процесс: Зомби-процесс — завершившийся процесс, чья запись остаётся в таблице процессов до чтения кода завершения родителем; он не выполняет инструкции.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Сигнал процесса: Сигнал процесса — уведомление о событии в Unix-подобной ОС, которое ядро доставляет процессу или потоку для выполнения заданного действия.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Файловый дескриптор: Файловый дескриптор — целочисленный идентификатор открытого объекта ввода-вывода в процессе Linux, через который ядро выполняет чтение, запись и другие операции.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
cgroup: cgroup — механизм ядра Linux для объединения процессов в иерархические группы с раздельным учётом и управлением потреблением ресурсов.
iowait: iowait — состояние учёта времени CPU в Linux, когда процессор простаивает при наличии задач, ожидающих завершения операций ввода-вывода.
Load average: Load average — среднее число задач Linux, выполняющихся или готовых к выполнению на CPU либо находящихся в непрерываемом ожидании, за 1, 5 и 15 минут.
Nice: Nice — числовой параметр относительного приоритета потока Linux, влияющий на его вес при распределении CPU между конкурирующими задачами.
PID: PID — числовой идентификатор экземпляра процесса, назначаемый ядром Linux для его адресации; после завершения процесса номер может быть использован повторно.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
Steal time: Steal time — показатель гостевой ОС: время, когда её vCPU был готов к выполнению, но гипервизор не предоставлял ему процессорный ресурс.
Swap: Swap — область на диске или SSD, используемая ядром Linux для размещения вытесненных страниц памяти, когда RAM требуется более активным данным.
systemctl: systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd: systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
ulimit: ulimit — встроенная команда оболочки для просмотра и изменения мягких и жёстких лимитов ресурсов текущего процесса оболочки, наследуемых его потомками.