📁 Процессы Linux

Короткий ответ Процесс — независимая единица выполнения со своим адресным пространством памяти, поток — единица выполнения внутри процесса, разделяющая с другими потоками того же процесса память и файловые дескрипторы; список процессов смотрят командой ps aux или ps -ef. Как это работает подробнее Ядро планирует как процессы, так и потоки, но у процесса отдельное виртуальное адресное пространство, а потоки одного процесса используют общее адресное пространство, из-за чего переключение между потоками дешевле, а обмен данными между процессами требует явного межпроцессного взаимодействия. Пример кода Что использовать на практике Практика. ps aux даёт снимок всех процессов с CPU/MEM, а ps -eLf или top с режимом Threads (клавиша H) показывает потоки внутри процессов — это полезно при диагностике приложений, которые упираются в производительность одного потока. Подводные камни Риск. Частая ошибка — путать «высокую загрузку CPU процессом» с «утечкой памяти процессом» просто по одной колонке в ps, не проверяя, растёт

Читать полностьюcpu

Короткий ответ Сначала находят процесс через top/htop или ps aux --sort=-%cpu/-%mem, проверяют его роль (сервис, дочерний воркер, однократная задача) командами ps -o ppid,cmd и systemctl status, затем останавливают максимально безопасным способом: через штатный механизм сервиса (systemctl restart) или SIGTERM с ожиданием, а не сразу SIGKILL. Как это работает подробнее Высокое потребление CPU или памяти может быть симптомом, а не причиной: например, утечка памяти в коде приложения, бесконечный цикл из-за некорректных входных данных, либо нормальная, но временная фоновая задача (переиндексация, компакция); разница принципиальна, потому что в первом случае процесс нужно останавливать и чинить код, а во втором — дождаться завершения или перенести на менее загрученное время. Пример кода Что использовать на практике Практика. перед остановкой стоит снять диагностические данные (jstack/py-spy/perf top в зависимости от рантайма, либо хотя бы strace -p для короткого среза системных вызовов) — это может быть единственн

Читать полностьюcpu

Короткий ответ nice-значение (от -20 до 19, по умолчанию 0) влияет на вес процесса в планировщике CPU: чем ниже значение (более отрицательное), тем выше приоритет и больше доля CPU при конкуренции; renice меняет это значение для уже запущенного процесса. Как это работает подробнее В планировщике CFS (Completely Fair Scheduler, используемом по умолчанию на большинстве дистрибутивов) nice-значение преобразуется в вес, который определяет долю процессорного времени, выделяемую процессу относительно других процессов на той же очереди при конкуренции за CPU; это влияет только на распределение времени при нехватке CPU, а не является жёстким лимитом или гарантией. Пример кода Что использовать на практике Практика. nice/renice полезны для фоновых пакетных задач (резервное копирование, пережатие логов), которым можно отдавать CPU по остаточному принципу, не мешая интерактивным или высокоприоритетным сервисам; для системного администратора требуется право CAP_SYS_NICE, чтобы понижать niceness (повышать приоритет) чужих

Читать полностьюlinux

Короткий ответ kill отправляет сигнал по числовому PID, pkill — по совпадению имени процесса или другим атрибутам (без явного PID), killall — по точному имени исполняемого файла; все три по умолчанию посылают SIGTERM, если сигнал не указан явно. Как это работает подробнее kill — это обёртка над системным вызовом kill(2), которой нужен конкретный идентификатор процесса; pkill и killall используют procfs или библиотеку для поиска процессов по шаблону имени или другим критериям (пользователь, терминал) и затем сами вызывают kill(2) для каждого найденного PID. Пример кода Что использовать на практике Практика. pkill/killall удобны, когда нужно остановить все копии процесса с одинаковым именем (например, все worker-процессы), но перед использованием стоит сначала выполнить pgrep или pkill с флагом -l/--signal 0 в режиме просмотра, чтобы убедиться, что под шаблон не попали лишние процессы. Подводные камни Риск. Частая ошибка — выполнить killall с общим именем вроде python или node на многопользовательском сервере и

Читать полностьюlinux

Короткий ответ Сначала проверяют, установлен ли в приложении обработчик SIGTERM и что именно он делает (возможно, зависает на внешнем вызове или ожидании соединения); если SIGTERM полностью игнорируется или обработчик завис, супервизор (systemd, оркестратор контейнеров) по истечении тайм-аута принудительно пришлёт SIGKILL. Как это работает подробнее SIGTERM, в отличие от SIGKILL, можно перехватить, заблокировать или проигнорировать на уровне приложения через sigaction(); если обработчик пытается, например, дождаться ответа от уже недоступной базы данных или завершить все активные соединения без тайм-аута, процесс может «зависнуть» в graceful shutdown бесконечно, пока его не остановят силой. Пример кода Что использовать на практике Практика. правильная graceful shutdown-логика должна иметь собственный внутренний тайм-аут (например, 10–30 секунд на дренаж соединений), после которого процесс завершает себя сам, не полагаясь только на внешний TimeoutStopSec в systemd или terminationGracePeriodSeconds в Kubernetes

Читать полностьюgraceful-shutdown

Короткий ответ Зомби-процесс — завершившийся процесс, запись о котором (код завершения) ещё не была считана родительским процессом через системный вызов wait(); он возникает, когда родитель не вызывает wait/waitpid вовремя или вообще. Как это работает подробнее После завершения процесса ядро сохраняет минимальную запись в таблице процессов (PID, код возврата) до тех пор, пока родитель не заберёт эту информацию; если родитель этого не делает, запись остаётся в состоянии Z (zombie) в выводе ps. Пример кода Что использовать на практике Практика. единичные кратковременные зомби — это нормально и не требуют действий, а накопление множества зомби говорит о баге в родительском процессе, который не обрабатывает завершение дочерних процессов; зомби сами по себе не занимают память, но исчерпывают таблицу PID. Подводные камни Риск. Частая ошибка — пытаться «убить» зомби сигналом kill: это бесполезно, так как процесс уже мёртв, нужно разбираться с родительским процессом (перезапустить его либо исправить код, чтобы он выз

Читать полностьюlinux

Короткий ответ Orphan-процесс — процесс, родитель которого завершился раньше него; операционная система автоматически переназначает такому процессу нового родителя — как правило, процесс инициализации (systemd с PID 1 или специально выделенный subreaper), который затем обязан вызывать wait() для освобождения завершившихся осиротевших процессов. Как это работает подробнее Когда родительский процесс завершается, пока у него ещё есть живые дочерние процессы, ядро репарентит (reparent) их на init (PID 1) или на ближайший процесс-предок, помеченный флагом PR_SET_CHILD_SUBREAPER (это умеют делать системы управления процессами вроде systemd, tini, s6); именно поэтому init обязательно должен уметь обрабатывать wait() для чужих детей, иначе они превратятся в зомби без возможности когда-либо быть «собранными». Пример кода Что использовать на практике Практика. проблема особенно актуальна в контейнерах: если в контейнере PID 1 — это само приложение, а не init-подобный процесс, оно может не вызывать wait() для осиротевши

Читать полностьюlinux

Короткий ответ PID (Process ID) — уникальный идентификатор процесса, PPID (Parent PID) — идентификатор процесса, который его породил; узнать родителя можно командой ps -o pid,ppid,cmd -p PID или построив дерево через pstree. Как это работает подробнее При создании нового процесса системный вызов fork() копирует вызывающий процесс, а exec() заменяет его образ новой программой; PPID сохраняется и указывает, кто инициировал запуск, формируя иерархическое дерево процессов вплоть до init/systemd с PID 1. Пример кода Что использовать на практике Практика. дерево процессов помогает понять, кто перезапускает «зависающий» сервис (например, systemd или супервизор), а также безопасно останавливать именно нужную ветку процессов, а не убивать всё по имени. Подводные камни Риск. Частая ошибка — считать, что PID сохраняется при перезапуске сервиса: systemd и большинство супервизоров выдают процессу новый PID при каждом старте, поэтому скрипты не должны жёстко хардкодить PID.

Читать полностьюlinux