Процессы и управление заданиями

Предыдущие темы показали работу с файлами, текстом, правами и потоками, но команды выполнялись как будто мгновенно. Что происходит внутри системы между нажатием Enter и появлением приглашения, рассмотрим сейчас. Программа, которая выполняется, — это процесс (англ. process). Каждая команда, скрипт и сетевой сервер — процессы. Умение видеть процессы, понимать их состояния и посылать им сигналы нужно для диагностики: зависшая программа или забитый процессор решаются именно этими средствами. Вводное изложение дано в учебнике Шоттса ².

Примеры выполнялись в Bash на Ubuntu (WSL2). Вывод, зависящий от состояния системы (номера процессов, время, набор программ), приведён реальным; сокращения оговорены в тексте. Для учебных экспериментов в лабораторной работе используются четыре программы из окружения: worker.sh, zombie.py, cpu_hog.sh и openmany.py.

Программа и процесс

Что такое процесс

Программа (англ. program) — это файл на диске: набор машинных инструкций и данных, например /usr/bin/sleep. Пока программа лежит на диске, она ничего не делает. Процесс (англ. process) — это программа, загруженная в память и выполняющаяся. Одну и ту же программу можно запустить несколько раз: тогда будет несколько процессов с одним и тем же исполняемым файлом, но разной памятью, разными открытыми файлами и разным состоянием.

Ядро операционной системы ведёт таблицу процессов: для каждого процесса в ней хранятся идентификатор, владелец, состояние, открытые файлы, объём памяти и родитель. Пользовательские программы получают эти сведения через системные вызовы, а утилиты ps и pstree читают их из каталога /proc. Такой подход типичен для UNIX: состояние системы доступно как текст, что соответствует философии «текст как интерфейс» (тема 1).

Для команды sleep это хорошо видно: программа одна, процессов может быть много.

sleep 900 &
sleep 901 &
ps -o pid,stat,comm,args -C sleep

    PID STAT COMMAND         COMMAND
   9156 S    sleep           sleep 900
   9157 S    sleep           sleep 901

Оба процесса выполняют один и тот же исполняемый файл /usr/bin/sleep, но имеют разные номера и разные аргументы. Поэтому при разборе системы важно смотреть не только на имя программы, но и на полную командную строку (колонка args в примере выше).

Идентификаторы процесса

Каждому процессу ядро присваивает целое число — идентификатор процесса, PID (англ. process identifier). Номера выдаются по возрастанию, и после перезагрузки счёт начинается заново. Номер уникален только в данный момент: после завершения процесса его номер через некоторое время может получить другой процесс. Поэтому скрипты, которые сохраняют PID в файл, должны учитывать, что процесс мог уже завершиться.

Кроме собственного номера, у процесса есть номер родителя — PPID (англ. parent process identifier). Родитель — это процесс, который создал данный процесс. Так образуется дерево: каждый процесс, кроме самого первого, имеет ровно одного родителя. Оболочка, в которой вы набираете команды, — родитель всех запущенных из неё программ. Сведения о процессах удобно смотреть вместе: ps -o pid,ppid,comm выводит оба номера.

Текущая оболочка знает свой номер в переменной $$, а номер последнего фонового процесса — в переменной $!. Эти переменные полезны в скриптах, поскольку позволяют отправить сигнал именно нужному процессу.

sleep 902 &
echo "PID оболочки: $$"
echo "PID фонового sleep: $!"
ps -o pid,ppid,stat,comm -p $$,$!

PID оболочки: 9155
PID фонового sleep: 9159
  PID  PPID STAT COMMAND
 9155  9152 S    bash
 9159  9155 S    sleep

Колонка PPID у фонового sleep равна PID оболочки: именно оболочка создала процесс. Номер родителя самой оболочки (9152) — процесс, который её породил, например эмулятор терминала или сервер удалённого входа. Номера в примере условные: при каждом запуске они различаются.

Дерево процессов

Утилита pstree строит дерево наглядно. Флаг -p добавляет PID в скобках. Для проверки воспроизведём ситуацию, в которой оболочка запустила конвейер из двух программ и ещё одну фоновую команду.

sleep 1101 | sleep 1102 &
sleep 1103 &
pstree -p $$

bash(11431)─┬─pstree(11435)
            ├─sleep(11432)
            ├─sleep(11433)
            └─sleep(11434)

Все четыре дочерних процесса принадлежат оболочке bash с номером 11431. Команда pstree сама является её дочерним процессом (11435). Два процесса конвейера sleep 1101 | sleep 1102 выглядят в дереве как два независимых ребёнка оболочки, но по колонке PGID в следующем выводе видно, что они образуют одну группу процессов: номер группы у обоих равен 11432 — PID первого процесса конвейера.

ps -o pid,ppid,pgid,sid,stat,tty,comm --ppid $$

  PID  PPID  PGID   SID STAT TT       COMMAND
11432 11431 11432 11431 S    pts/5    sleep
11433 11431 11432 11431 S    pts/5    sleep
11434 11431 11434 11431 S    pts/5    sleep
11516 11431 11516 11431 R+   pts/5    ps

Группа процессов (англ. process group) — набор процессов, которыми оболочка управляет как единым целым: сигнал можно отправить всей группе, а управление терминалом передаётся группе целиком. Конвейер — это группа, поэтому Ctrl+C прерывает весь конвейер. Колонка SID показывает сеанс (англ. session) — набор групп, связанных с одним терминалом. Группа переднего плана отмечена знаком + в колонке STAT.

Заметим, что процесс ps в последней строке имеет состояние R+: он выполняется прямо сейчас (R) и находится в группе переднего плана (+). Смысл букв состояния рассмотрен ниже.

Процесс init и происхождение процессов

Если идти по цепочке родителей вверх, придём к процессу с номером 1. В классических системах UNIX и в Ubuntu это init (в Ubuntu — systemd), который ядро запускает первым. Он порождает системные службы и становится приёмным родителем для «осиротевших» процессов, о которых пойдёт речь ниже.

В среде WSL2, где выполнялись примеры, процесс 1 имеет другой вид: он называется /init и запускается инфраструктурой подсистемы, а не systemd. Вторая колонка COMMAND (args) содержит полную командную строку процесса.

ps -p 1 -o pid,comm,args

  PID COMMAND         COMMAND
    1 init(Ubuntu-24. /init

Название init(Ubuntu-24. в колонке COMMAND обрезано ядром до 15 символов, поэтому полная строка /init видна только в колонке args. Это частая особенность: короткое имя процесса (comm) не всегда совпадает с командной строкой (args), и при поиске нужного процесса следует смотреть на обе колонки.

Создание процессов: fork, exec и wait

Как оболочка запускает программу

Когда в терминале набрана команда ls -l и нажата клавиша Enter, оболочка должна выполнить /usr/bin/ls и дождаться завершения. Ядро не предоставляет единого вызова «запустить программу» как основного механизма UNIX. Вместо этого используются два более простых действия, заложенных ещё в ранних версиях системы ¹. Первое — fork («раздвоение»): текущий процесс создаёт почти точную копию. Второе — exec («замена»): процесс заменяет свою программу на другую, загруженную из файла. Оболочка выполняет fork, в ребёнке — exec, а родитель ждёт завершения ребёнка.

Схема на рисунке показывает эту последовательность для команды ls -l в оболочке.

После fork у ребёнка те же открытые файлы, переменные окружения и текущий каталог, что и у родителя. Поэтому перенаправление, которое оболочка задала до запуска команды (тема 5), действует и в ребёнке. Замена программы через exec сохраняет PID, открытые файлы и окружение: меняется только код, поэтому в ps процесс не получает нового номера.

Трассировка системных вызовов

Наблюдать эту последовательность можно напрямую: утилита strace выводит системные вызовы процесса. Ограничим вывод вызовами создания процессов и ожидания их завершения. Команда bash -c с двумя командами через точку с запятой запускает ls в отдельном процессе, поскольку только так видны fork и exec.

strace -f -qq -e trace=clone,clone3,execve,wait4,exit_group bash -c 'ls /etc/hostname; echo done' 2>&1 | grep -v resumed

execve("/usr/bin/bash", ["bash", "-c", "ls /etc/hostname; echo done"], 0x7fff37eadd30 /* 48 vars */) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x706b82eb7a10) = 9105
[pid 9104] wait4(-1,  <unfinished ...>
[pid 9105] execve("/usr/bin/ls", ["ls", "/etc/hostname"], 0x592988c86190 /* 48 vars */) = 0
/etc/hostname
[pid 9105] exit_group(0)               = ?
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9105, si_uid=1000, si_status=0, si_utime=0, si_stime=1} ---
wait4(-1, 0x7ffec14b2ad0, WNOHANG, NULL) = -1 ECHILD (No child processes)
done
exit_group(0)                           = ?

Трасса показывает весь сценарий. Процесс 9104 (оболочка) выполняет clone, появляется ребёнок 9105. В нём вызывается execve с программой /usr/bin/ls. Оболочка вызывает wait4 и блокируется, пока ребёнок не завершится; ядро посылает ей SIGCHLD, и wait4 возвращает код завершения. Последний wait4 с флагом WNOHANG возвращает ECHILD: детей больше нет. Строка done — вывод второй команды, которую оболочка выполнила сама.

Ожидание завершения и код возврата

Вызов wait (в виде системного вызова wait4) выполняет две задачи. Во-первых, родитель узнаёт, что ребёнок завершился. Во-вторых, родитель забирает код возврата ребёнка — число, которое программа передала при завершении. По соглашению, код 0 означает успех, а любой другой код — ошибку. Именно этот код оболочка сохраняет в переменной $?, и на нём основаны операторы && и || (тема 5).

ls /etc/hostname; echo "код: $?"
ls /нет/такого/каталога; echo "код: $?"

/etc/hostname
код: 0
ls: cannot access '/нет/такого/каталога': No such file or directory
код: 2

Код 2 — стандартный код ошибки утилиты ls при неверном аргументе. Текст сообщения здесь английский, поскольку в примере использована английская локаль; на русской системе сообщение будет переведено, а код останется тем же. Сам процесс-ребёнок сообщил о нём через код завершения, и оболочка получила его через wait. Заметим, что сообщение об ошибке ушло в поток stderr, а код возврата — отдельный канал информации. Оба механизма нужны для диагностики.

Если родитель не вызывает wait, код возврата ребёнка не забирается, и ребёнок остаётся в таблице процессов в виде зомби. Эта ситуация будет подробно рассмотрена в разделе о состояниях процесса, а в лабораторной работе зомби создаётся намеренно.

Фоновый запуск и конвейеры

Знак & в конце команды сообщает оболочке, что не нужно ждать завершения процесса: оболочка выполняет fork, в родителе сразу печатает приглашение, а ребёнок работает в фоне (background). Номер последнего фонового процесса доступен через $!. Для конвейера оболочка создаёт по процессу на каждую команду; все они выполняются одновременно и связаны каналами (тема 5).

Фоновый процесс остаётся дочерним процессом оболочки. Пока оболочка жива, она получает SIGCHLD и вызывает wait. Если же оболочка завершилась раньше фонового процесса, тот становится сиротой и переходит к процессу 1. Так объясняется, почему задания иногда «исчезают» при закрытии терминала, — см. раздел «Управление заданиями».

Состояния процессов и наблюдение

Состояния процесса

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

Состояние D заслуживает особого внимания. Процесс в нём не реагирует даже на SIGKILL, потому что ждёт завершения операции с диском, которую нельзя отменить. Долгое пребывание в D — признак проблемы с устройством или файловой системой. В учебной среде это состояние трудно воспроизвести, поэтому в лабораторной работе оно не используется; описание дано по ps ⁷.

Процесс в состоянии S не потребляет процессор, поэтому большинство процессов обычной системы находятся именно в нём. Подсчитаем первую букву колонки STAT для всех процессов текущей машины.

ps -eo stat= | cut -c1 | sort | uniq -c

      1 R
     40 S

В момент измерения на процессор претендовал один процесс — сама команда ps, — а сорок процессов ждали событий. Такая картина типична для простаивающей системы: процессор почти не занят, и большая часть процессов спит.

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

Состояние T возникает при сигналах SIGTSTP (Ctrl+Z) и SIGSTOP. Проверим второй случай: приостановим фоновый процесс sleep сигналом SIGSTOP и вернём его сигналом SIGCONT.

sleep 910 &
P=$!
kill -STOP $P; sleep 0.2; ps -o pid,stat,comm -p $P
kill -CONT $P; sleep 0.2; ps -o pid,stat,comm -p $P
kill $P

  PID STAT COMMAND
17052 T    sleep
  PID STAT COMMAND
17052 S    sleep

После SIGSTOP процесс перешёл в состояние T, после SIGCONT вернулся в S: остановка не сбрасывает его состояние ожидания.

Колонка STAT в ps aux

Команда ps aux — самый распространённый способ увидеть все процессы системы. Её заголовок содержит колонку STAT, в которой, помимо основной буквы состояния, могут стоять дополнительные символы. Пример строки заголовка и строки процесса:

ps aux | head -1
ps aux | grep -E " 17067 " | grep -v grep

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
student     17067  0.0  0.0   3216  1792 ?        S    13:58   0:00 sleep 910

Колонки: USER — владелец; PID — номер; %CPU и %MEM — доля процессорного времени и памяти; VSZ и RSS — виртуальный размер и объём в физической памяти (в килобайтах); TTY — терминал (знак ? означает его отсутствие); START и TIME — время запуска и накопленное процессорное время; COMMAND — командная строка.

Дополнительные символы в STAT читаются так: s — процесс является лидером сеанса (обычно это оболочка); + — процесс находится в группе переднего плана терминала; < — повышенный приоритет; N — пониженный приоритет (значение nice больше нуля, см. раздел о приоритетах); l — процесс многопоточный. Так, строка Ss у оболочки означает «спящая, лидер сеанса», а R+ у команды ps — «выполняется, на переднем плане».

Зомби и сироты

Зомби (англ. zombie) — процесс, который уже завершился, но запись о нём осталась в таблице процессов, пока родитель не вызвал wait. Он не потребляет процессор и память, но занимает место в таблице; при большом их количестве ядро не может создавать новые процессы. Сигнал мёртвому процессу бесполезен, поэтому устранить зомби можно только одним способом: завершить родителя (или заставить его вызвать wait). Тогда зомби передаётся процессу-приёмному родителю, который забирает своих детей и убирает зомби. Этот приём используется в лабораторной работе.

Сирота (англ. orphan) — процесс, родитель которого завершился раньше него. Сирота не становится зомби: ядро передаёт его процессу-приёмному родителю, которым в Ubuntu служит процесс 1, а в WSL2 — /init. Разница между зомби и сиротой важна: зомби уже мёртв и ждёт, пока родитель его заберёт; сирота жив и работает.

Проверим создание зомби с помощью учебной программы zombie.py из окружения лабораторной работы. Родитель создаёт дочерний процесс, тот сразу завершается, а родитель спит и не вызывает wait.

python3 zombie.py 120 &
sleep 1
ps -o pid,ppid,stat,comm --ppid $!

  PID  PPID STAT COMMAND
22310 22306 Z    python3 <defunct>

Запись <defunct> в колонке COMMAND означает, что процесс мёртв; состояние Z подтверждает это. Родитель (PID 22306) продолжает спать, поэтому зомби остаётся. Когда родитель завершится, зомби исчезнет:

kill -TERM 22306
sleep 1
ps -o pid,ppid,stat,comm -p 22310

  PID  PPID STAT COMMAND

Пустой вывод означает, что процесса 22310 больше нет. Отправка сигнала самому зомби (например, kill -9 22310) не даёт результата: команда kill возвращает код 0, но зомби продолжает стоять в таблице, так как уже мёртв. Именно это различие проверяется в лабораторной работе.

Инструменты наблюдения

Для наблюдения используются утилиты ps (снимок состояния), top (обновляемая картина с сортировкой по нагрузке), pgrep (поиск PID по шаблону) и lsof (открытые файлы). Состояния процессов в UNIX и Linux общие для всех систем этого семейства ⁴.

Самый прямой источник сведений — каталог /proc: виртуальная файловая система, которую ядро формирует при чтении. Для каждого процесса в /proc/<pid>/ есть файл status с состоянием, cmdline с командной строкой (аргументы разделены нулевыми байтами), каталог fd с открытыми файлами и ссылка exe на исполняемый файл. Все файлы описаны в справочной странице proc(5) ⁷.

sleep 910 &
P=$!
sleep 0.3
grep -E '^(Name|State|Tgid|Pid|PPid|Uid|Threads|VmRSS):' /proc/$P/status
tr '\0' ' ' < /proc/$P/cmdline; echo

Name:	sleep
State:	S (sleeping)
Tgid:	17067
Pid:	17067
PPid:	17066
Uid:	1000	1000	1000	1000
VmRSS:	    1792 kB
Threads:	1
sleep 910 

Поля Pid и Tgid совпадают, потому что процесс однопоточный; у многопоточной программы Tgid — номер группы потоков. Колонка Uid содержит идентификаторы пользователя и по ней определяется владелец. Команда ls -l /proc/<pid>/fd показывает открытые файлы процесса: стандартные потоки 0, 1 и 2 из темы 5. У процесса, запущенного из интерактивной оболочки без перенаправлений, все три ссылки указывают на терминал, например /dev/pts/0; при перенаправлении ссылка указывает на соответствующий файл.

Утилита top в пакетном режиме (-b) выводит одну итоговую картину и полезна для скриптов. Строки заголовка показывают общую загрузку, а таблица — процессы с наибольшей нагрузкой. Ниже приведён фрагмент вывода во время работы cpu_hog.sh.

./cpu_hog.sh 25 &
sleep 2
top -b -n1 | head -8

top - 13:16:34 up 40 min,  0 users,  load average: 6.93, 2.74, 1.50
Tasks:  60 total,   2 running,  58 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.5 us,  5.4 sy,  0.0 ni, 64.1 id, 10.3 wa,  0.0 hi,  1.6 si,  0.0 st
MiB Mem :   7915.2 total,   5140.2 free,   1333.8 used,   1441.3 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   6400.6 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
23311 student      20   0    4788   3328   3072 R 100.0   0.0   0:02.37 bash

В строке Tasks видно число процессов в каждом состоянии, включая зомби (0 zombie). Строка %Cpu(s) разбивает загрузку процессора: us — пользовательские программы, sy — ядро, id — простой, wa — ожидание ввода-вывода. Процесс bash с номером 23311 — это cpu_hog.sh: его командная строка видна в ps, а top показывает имя исполняемого файла. Это и есть задача из лабораторной работы: найти пожирателя CPU.

Имя в колонке COMMAND не всегда совпадает с тем, что запущено: скрипт на Bash выполняется процессом bash, и имя скрипта видно только в колонке args.

Сигналы

Что такое сигнал

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

Сигналы приходят из нескольких источников. Ctrl+C в терминале вызывает SIGINT, Ctrl+Z — SIGTSTP, ядро посылает SIGCHLD родителю при завершении ребёнка, команда kill отправляет любой сигнал по выбору пользователя. Посылать сигнал можно процессу своего пользователя; попытка отправить сигнал чужому процессу без прав завершается ошибкой «Operation not permitted».

Сигнал обозначают именем (SIGTERM) или номером (15); для x86-64 номера стандартизированы. Полный список выводит kill -l. В сокращённой записи начало списка выглядит так:

kill -l

 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
...

Номера 32 и 33 зарезервированы библиотекой GNU C; сигналы реального времени (34 и далее) здесь не рассматриваются. Далее в тексте используются только сигналы из таблицы ниже.

Таблица основных сигналов

Таблица содержит сигналы, которые встречаются на практике: их действие по умолчанию, и можно ли перехватить сигнал программой. Описание взято из справочной страницы signal(7) ⁷.

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

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

Перехват сигнала и поведение программы

Программа может заменить действие по умолчанию собственным обработчиком (англ. handler): при получении сигнала выполняется её код, после чего работа продолжается, например сохраняются данные или удаляются временные файлы. В скриптах Bash обработчики задаются командой trap (тема 15); в лабораторной работе они уже написаны в worker.sh. Устройство обработки сигналов в UNIX подробно описано в книге Керриска ³.

Игнорирование сигнала означает, что программа не реагирует на него вовсе. Оболочка делает это по умолчанию для фоновых команд, запущенных без управления заданиями, то есть из скрипта: в этом можно убедиться экспериментально. Ниже скрипт запускает worker.sh в фоне и посылает ему по очереди сигналы SIGINT, SIGQUIT и SIGUSR1; после каждого проверяется состояние процесса.

#!/usr/bin/env bash
$HOME/lab-07/lr-env/worker.sh >/tmp/int.log 2>&1 &
p=$!
sleep 1.5
kill -INT $p
sleep 1.2
echo "после SIGINT: $(ps -o stat= -p $p 2>/dev/null || echo нет процесса)"
kill -QUIT $p
sleep 1.2
echo "после SIGQUIT: $(ps -o stat= -p $p 2>/dev/null || echo нет процесса)"
kill -USR1 $p
sleep 1.2
echo "после SIGUSR1: $(ps -o stat= -p $p 2>/dev/null || echo нет процесса)"

после SIGINT: S
после SIGQUIT: S
/tmp/sigtest.sh: line 12: 21206 User defined signal 1   /home/student/lab-07/lr-env/worker.sh > /tmp/int.log 2>&1
после SIGUSR1: нет процесса

Сигналы SIGINT и SIGQUIT не завершили процесс: фоновое задание неинтерактивной оболочки получает их игнорируемыми. Сигнал SIGUSR1 завершил процесс, поскольку ни worker.sh, ни оболочка не назначили ему обработчик, а действие по умолчанию — завершение. Оболочка сообщила о «User defined signal 1» и кодом возврата 138 (128 + 10). Код выхода 128 плюс номер сигнала — стандартная запись для процессов, убитых сигналом.

В интерактивной оболочке с управлением заданиями картина иная: фоновое задание получает SIGINT с действием по умолчанию, и kill -INT завершает worker.sh с кодом 130 (128 + 2). Эта разница проверяется в лабораторной работе.

kill, pkill и killall

Команда kill отправляет сигнал по PID в виде kill [-СИГНАЛ] PID. Без имени сигнала отправляется SIGTERM. Записи kill -9 1234, kill -KILL 1234 и kill -s SIGKILL 1234 эквивалентны. Сигнал 0 не воздействует на процесс, но позволяет проверить, существует ли он.

Команда pkill ищет процессы по шаблону имени и отправляет им сигнал. Ключ -x требует точного совпадения имени, -f ищет шаблон в полной командной строке. Команда killall работает по точному имени программы и без явного шаблона отправит сигнал всем процессам с этим именем, включая те, которые не принадлежат задаче. Поэтому killall на общем сервере опасен.

Осторожность при pkill -f обязательна: шаблон сравнивается с полной командной строкой, и под удар может попасть сама оболочка, которая запустила pkill. Безопасный приём — сначала выполнить pgrep -a с тем же шаблоном и убедиться в списке совпадений.

Почему сначала отправляют SIGTERM, а не SIGKILL? SIGTERM даёт программе возможность аккуратно завершиться: сохранить данные, закрыть файлы, удалить временные каталоги. SIGKILL завершает процесс мгновенно, и всё незавершённое остаётся как есть: повреждённые файлы, неосвобождённые блокировки. Правило «сначала TERM, затем KILL» означает, что сильный сигнал применяется, только если мягкий не сработал за разумное время.

./worker.sh >/tmp/w.log 2>&1 &
W=$!
sleep 2.5
kill -TERM $W
wait $W; echo "код возврата: $?"
cat /tmp/w.log

код возврата: 0
worker.sh запущен, PID 20586
13:16:01  тик 1
13:16:02  тик 2
13:16:03  тик 3
[worker 20586] получен SIGTERM: очистка (1 с) и выход
[worker 20586] очистка завершена

Процесс завершился с кодом 0, а не 143: обработчик SIGTERM вызвал exit 0 после очистки. Если бы обработчика не было, код возврата был бы 143 (128 + 15), а сообщения очистки не появились бы вовсе. Тот же сигнал SIGKILL даёт код 137 и не оставляет следов в журнале: программа не получает возможности что-либо сообщить.

Управление заданиями в интерактивной оболочке

Фоновый запуск и список заданий

Интерактивная оболочка позволяет вести несколько программ одновременно: одна занимает терминал, другие работают в фоне. Набор процессов, которым оболочка управляет как единым целым, называется заданием (англ. job). Оболочка нумерует задания и отличает задание переднего плана от фоновых. Механизмы описаны в стандарте POSIX ⁸ и в руководстве по Bash ⁶.

Команда jobs выводит список заданий текущей оболочки. Задания нумеруются в квадратных скобках — это номер задания, а не PID; отдельно выводится PID процесса при флаге -l. Знак + отмечает задание, над которым работают fg и bg по умолчанию, знак - — предыдущее задание. Ниже запускается фоновый процесс и выводится список.

$ sleep 100 &
[1] 24166
$ jobs
[1]+  Running                 sleep 100 &

Задания остаются в списке, пока процессы работают. Номер задания используется в командах fg, bg, kill и wait в форме %N: %1 — первое задание, %% — текущее. Без процентного знака kill 1 отправил бы сигнал процессу init, поэтому внимательность при указании номера важна.

Ctrl+Z, fg и bg

Нажатие Ctrl+C отправляет SIGINT группе переднего плана и обычно прерывает программу. Ctrl+Z отправляет SIGTSTP: программа останавливается, но не завершается и может быть продолжена. Команда bg продолжает остановленное задание в фоне, fg переводит задание на передний план и отдаёт ему терминал.

Процесс, остановленный сигналом SIGTSTP, находится в состоянии T: он не потребляет процессор, но занимает память. Забытые остановленные задания — частая причина лишней нагрузки в длинной сессии, поэтому полезно проверять jobs. Ниже приведена сессия в интерактивной оболочке Bash в псевдотерминале: строки с приглашением $ введены вручную, остальные — вывод оболочки.

$ sleep 100 &
[1] 24166
$ jobs
[1]+  Running                 sleep 100 &
$ sleep 200
^Z
[2]+  Stopped                 sleep 200
$ jobs
[1]-  Running                 sleep 100 &
[2]+  Stopped                 sleep 200
$ bg %2
[2]+ sleep 200 &
$ jobs
[1]-  Running                 sleep 100 &
[2]+  Running                 sleep 200 &
$ fg %2
sleep 200
^C
$ jobs
[1]+  Running                 sleep 100 &

Команда sleep 200 была запущена на переднем плане, поэтому приглашение не возвращалось. Ctrl+Z перевёл её в состояние «Stopped». Команда bg %2 продолжила задание в фоне (знак & в выводе), а fg %2 вернула его на передний план; Ctrl+C его прервало. Задание 1 всё это время работало независимо.

Схема на рисунке показывает переходы задания между состояниями и клавиши, которые их вызывают.

Фоновое задание, которое обращается к терминалу для чтения, получает SIGTTIN и останавливается, а при записи — SIGTTOU (см. таблицу сигналов). Это защита: двум программам нельзя одновременно отвечать на одни и те же нажатия клавиш. Фоновая программа, которой нужен ввод, переходит в состояние T и ждёт fg.

Отрыв от терминала: nohup и disown

Задание, запущенное в фоне, связано с терминалом. Если терминал закрыт или связь потеряна, ядро посылает управляющему процессу сеанса SIGHUP. Оболочка пересылает SIGHUP своим заданиям и завершается, поэтому фоновые задания гибнут вместе с терминалом. Это важно при работе по SSH, когда соединение может оборваться (тема 11).

Есть два способа защитить задание от SIGHUP. Команда nohup запускает программу с игнорируемым SIGHUP; её вывод при необходимости уходит в файл nohup.out ⁵. Команда disown удаляет задание из таблицы оболочки, и оболочка перестаёт посылать ему SIGHUP.

Проверим оба способа в одной интерактивной сессии. Процесс sleep 701 запускается обычным фоном, sleep 702 — фоном с последующим disown, sleep 703 — через nohup, sleep 704 — через nice. Затем оболочке посылается SIGHUP командой kill -HUP $$.

$ sleep 701 &
[1] 26939
$ sleep 702 &
[2] 26940
$ disown %2
$ nohup sleep 703 >/dev/null 2>&1 &
[2] 26941
$ nice -n 10 sleep 704 &
[3] 26942
$ jobs -l
[1]  26939 Running                 sleep 701 &
[2]- 26941 Running                 nohup sleep 703 > /dev/null 2>&1 &
[3]+ 26942 Running                 nice -n 10 sleep 704 &
$ echo shell=$$
shell=26928
$ kill -HUP $$

Команда disown %2 удалила sleep 702 из таблицы заданий, поэтому в jobs -l его нет. После отправки SIGHUP оболочка завершилась, а проверка процессов показала, что живы только два процесса:

pgrep -a -x sleep

26940 sleep 702
26941 sleep 703

Процессы sleep 701 и sleep 704 завершились: это обычные задания оболочки, и им переслан SIGHUP. Процесс sleep 702 выжил, потому что отделён командой disown, а sleep 703 защищён nohup, который делает SIGHUP игнорируемым. Заметим, что disown лишь убирает задание из-под управления оболочки, а nohup защищает от сигнала.

На практике для длинных задач используют терминальные мультиплексоры (тема 8) и службы systemd (тема 9), которые не зависят от сеанса входа.

Приоритеты и загрузка системы

Приоритеты: nice и renice

Процессор делит между процессами планировщик: процессы с более высоким приоритетом получают процессор чаще. Значение «любезности» (англ. niceness) меняется от -20 (наивысший приоритет) до 19 (наименьший); по умолчанию 0. Обычный пользователь может только понижать приоритет своих процессов; повышать — привилегия суперпользователя.

Команда nice запускает программу с заданным значением, а renice меняет значение у уже работающего процесса. Команда nice входит в набор GNU coreutils ⁵, а renice — в пакет util-linux. Ниже фоновому процессу sleep 1201 меняется приоритет с 0 на 5 командой renice, а затем проверяется результат.

sleep 1201 &
P1=$!
renice -n 5 -p "$P1"
ps -o pid,ni,stat,etime,args -p "$P1"

27348 (process ID) old priority 0, new priority 5
  PID  NI STAT     ELAPSED COMMAND
27348   5 SN         00:00 sleep 1201

Колонка NI показывает значение «любезности», а буква N в STAT — что приоритет понижен относительно нормы. Попытка уменьшить значение ниже текущего завершается ошибкой:

sleep 1301 &
renice -n -5 -p $!

renice: failed to set priority for 27351 (process ID): Permission denied

Приоритет полезен для фоновых расчётов, которые не должны мешать интерактивной работе: их запускают с nice -n 19. Приоритет не защищает от нагрузки на диск и память.

Загрузка системы: uptime и load average

Команда uptime показывает текущее время, время работы системы с момента загрузки, число вошедших пользователей и среднюю загрузку (load average). Средняя загрузка — это среднее число процессов, которые в данный момент выполняются (состояние R) или ждут ввода-вывода (состояние D), за последние 1, 5 и 15 минут.

uptime
cat /proc/loadavg

 13:58:50 up  1:22,  0 users,  load average: 0.20, 0.15, 0.49
0.20 0.15 0.49 2/308 17205

Файл /proc/loadavg содержит те же три числа, а также число готовых к работе процессов из общего числа (здесь 2 из 308) и последний выданный PID. Load average нужно сравнивать с числом ядер: на двенадцатиядерной системе значение 12 означает полную загрузку, а 1.0 — почти простой. Если значение за минуту заметно выше значения за 15 минут, нагрузка появилась недавно.

Load average учитывает и процессы в состоянии D. Поэтому высокая загрузка при почти свободном процессоре (строка wa в выводе top) означает, что система ждёт диск, а не вычисляет.

Для поиска процесса-«пожирателя» нагрузки удобно отсортировать список по колонке %CPU. В результате первая строка и содержит самого прожорливого потребителя процессора:

ps aux --sort=-%cpu | head -3

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
student     23311 79.0  0.0   4788  3328 ?        R    13:16   0:02 bash ./cpu_hog.sh 25

Строка с cpu_hog.sh в состоянии R и с наибольшим %CPU — это и есть искомый процесс. Заметим, что значение %CPU в ps aux — средняя доля процессорного времени за всю жизнь процесса, а в top — за последний интервал обновления. Для текущей картины нагрузки нужен top.

Память: free -h

Команда free показывает состояние оперативной памяти и области подкачки (swap). Ключ -h выводит величины в удобочитаемом виде (мегабайты и гигабайты).

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.2Gi       4.7Gi       3.0Mi       1.9Gi       6.4Gi
Swap:          2.0Gi          0B       2.0Gi

Самая важная колонка — available: объём памяти, который можно выделить новым программам без подкачки, с учётом освобождаемого кэша. Колонка free мала, потому что Linux использует свободную память под кэш файлов (buff/cache). Признак проблемы — маленький available и растущая колонка used в строке Swap: тогда система начинает подкачку, и быстродействие резко падает. Виновника ищут сортировкой ps aux --sort=-rss.

Ресурсы процесса и журнал ядра

До сих пор процесс рассматривался как объект, который можно увидеть и остановить. Остаётся вопрос, что процесс держит и сколько ему позволено. Он держит открытые файлы и сокеты, расходует память, а ядро ограничивает его пределами и в крайнем случае завершает, если памяти не хватает. Раздел собирает инструменты для этих задач: watch для повторяющегося наблюдения, lsof и /proc/PID/fd для открытых файлов, журнал ядра, OOM-killer и команды ulimit и prlimit.

watch: повторяющееся наблюдение

Многие проверки приходится повторять: растёт ли файл, исчез ли процесс, изменилась ли нагрузка. Команда watch из пакета procps запускает указанную команду заново через равные промежутки времени и показывает её вывод на весь экран. Команда задаётся одной строкой, поэтому конвейеры и подстановки заключают в кавычки: иначе их разберёт текущая оболочка, а не watch. Основные опции: -n секунды задаёт интервал (по умолчанию 2 секунды), -d подсвечивает символы, изменившиеся с прошлого запуска, -t убирает заголовок, -g завершает watch, когда вывод изменится. Прервать наблюдение можно сочетанием Ctrl+C ⁷.

watch -n 1 -d 'date +%S'

Ниже первый кадр: в первой строке интервал, команда, имя узла и время запуска, а ниже вывод команды. Имя узла заменено на host. Цифры, изменившиеся с прошлого кадра, терминал показывает в инверсном цвете; здесь это не видно.

Every 1.0s: date +%S                                host: Sun Oct 18 19:49:14 2026

14

Типичные применения: watch -n 1 'ps -o pid,stat,etime,comm -p PID' показывает, как меняется состояние процесса; watch -d 'ls -l /var/log/app.log' позволяет следить за ростом файла; watch -n 5 free -h показывает динамику памяти. Для обычного текстового потока вместо watch годится tail -f из темы 3, а watch удобнее, когда нужно перезапускать целую команду и сравнивать кадры. Так как watch занимает терминал и перерисовывает экран, в скриптах и в перенаправлении вывода в файл его не применяют: для скриптов служит цикл с sleep; циклы Bash рассматриваются в теме 14.

Открытые файлы: lsof и /proc/PID/fd

Каждый открытый файл в UNIX представлен числом, дескриптором: 0, 1 и 2 — стандартные потоки, следующие свободные номера получают файлы, которые процесс открыл сам. Сокеты, каналы и устройства тоже занимают дескрипторы, поэтому вопрос «что делает процесс» нередко сводится к вопросу «что у него открыто». Самый прямой ответ даёт каталог /proc/PID/fd, где каждый дескриптор — символическая ссылка на объект ⁷. Для веб-сервера, который слушает порт, там видны потоки, перенаправленные в /dev/null, и сокет.

python3 -m http.server 8765 --bind 127.0.0.1 >/dev/null 2>&1 &
H=$!
ls -l /proc/$H/fd

total 0
lr-x------ 1 student student 64 Oct 18 19:49 0 -> /dev/null
l-wx------ 1 student student 64 Oct 18 19:49 1 -> /dev/null
l-wx------ 1 student student 64 Oct 18 19:49 2 -> /dev/null
lrwx------ 1 student student 64 Oct 18 19:49 3 -> socket:[1368738]

Запись socket:[1368738] означает сокет с номером inode, но не говорит, на каком он порту. Эту информацию добавляет lsof (англ. list open files): он обходит /proc, собирает дескрипторы и показывает их в виде таблицы. Опция -p PID ограничивает вывод одним процессом, -i :порт ищет, кто использует сетевой порт, -u имя отбирает файлы пользователя, +D каталог рекурсивно находит процессы, держащие файлы внутри каталога. Опции -n и -P отключают преобразование адресов и портов в имена: вывод становится быстрее и однозначнее. Без прав root lsof видит только процессы текущего пользователя, чего достаточно для учебных задач.

lsof -i :8765
lsof -p $H | head -4

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
python3 11520 student    3u  IPv4 1368868      0t0  TCP localhost:8765 (LISTEN)
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
python3 11520 student  cwd    DIR    8,48     4096 678196 /home/student/demo
python3 11520 student  rtd    DIR    8,48     4096      2 /
python3 11520 student  txt    REG    8,48  5941864 265033 /usr/bin/python3.10

Вывод получен в Ubuntu 22.04, поэтому исполняемый файл называется python3.10; в Ubuntu 24.04 там будет python3.12, а остальные колонки те же. Разберём колонки. FD — дескриптор с режимом доступа: 3u значит чтение и запись, 4r только чтение, 5w только запись; вместо числа бывают служебные записи cwd (текущий каталог), rtd (корневой каталог), txt (исполняемый файл) и mem (подгруженные библиотеки). TYPE — тип объекта: REG обычный файл, DIR каталог, IPv4 сетевой сокет. NODE для сокета содержит протокол и состояние, для файла — номер inode. NAME показывает путь или адрес с портом, а состояние LISTEN говорит, что процесс ожидает соединений. Команда lsof -i :8765 — первое средство при ошибке «Address already in use»: она называет процесс, который занял порт.

Вторая частая задача — понять, кто мешает размонтировать или удалить каталог. Команда lsof +D и родственная fuser -v показывают процессы, у которых внутри каталога что-то открыто.

mkdir d && cd d
sleep 300 > out.txt &
cd ..
lsof +D d
fuser -v d/out.txt

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
sleep   10931 student  cwd    DIR   8,48     4096 678643 /home/student/demo/d
sleep   10931 student    1w   REG   8,48        0 678644 /home/student/demo/d/out.txt
                     USER        PID ACCESS COMMAND
/home/student/demo/d/out.txt:
                     student      10931 F.... sleep

Процесс sleep держит текущий каталог (cwd) и файл out.txt на дескрипторе 1, куда оболочка перенаправила его вывод. Если бы каталог был точкой монтирования, размонтирование завершилось бы ошибкой «target is busy», а виновника назвали бы именно lsof и fuser; подробно — в теме 10.

Особый случай — удалённый, но открытый файл. Команда rm лишь удаляет имя из каталога; данные остаются на диске, пока их держит хотя бы один процесс. Типичная ситуация на сервере: диск заполнен гигабайтами журнала, администратор удалил файл, а свободного места не прибавилось, потому что программа продолжает в него писать. Признак в /proc и lsof — пометка (deleted).

exec 7>/home/student/demo/big.log
echo data >&7
rm /home/student/demo/big.log
ls -l /proc/$$/fd/7
lsof +L1 -a -p $$
exec 7>&-

l-wx------ 1 student student 64 Oct 18 19:49 /proc/10237/fd/7 -> /home/student/demo/big.log (deleted)
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
bash    10237 student    7w   REG   8,48        5     0 579965 /home/student/demo/big.log (deleted)

Опция +L1 отбирает файлы, у которых меньше одной жёсткой ссылки (колонка NLINK равна 0): их имя удалено, а данные живы. Последняя команда exec 7>&- закрывает дескриптор, и только тогда ядро освобождает место. Для настоящего процесса есть два пути: перезапустить программу, чтобы она закрыла файл, или опустошить файл по ссылке : > /proc/PID/fd/N, не останавливая процесс. Как место на диске связано с inode и ссылками, рассказано в теме 10.

Журнал ядра: dmesg и journalctl -k

У ядра есть собственный журнал: кольцевой буфер фиксированного размера в памяти. Причина в том, что ядро начинает писать сообщения раньше, чем запускаются файловые системы, journald и вообще любой процесс. Сообщения об обнаружении оборудования, ошибках драйверов, подключении дисков и нехватке памяти нужно сохранить, даже если их некому принять. Когда буфер заполняется, новые сообщения вытесняют самые старые, поэтому давние события из dmesg исчезают. Уровни важности те же, что в journalctl -p: от emerg до debug.

Читает буфер команда dmesg. Каждая строка начинается со времени в секундах с момента запуска ядра. Опция -T переводит его в календарное время, -l (или --level) отбирает уровни, -x добавляет в строку название подсистемы и уровень, -w ожидает новые сообщения, подобно tail -f. В системах с включённым kernel.dmesg_restrict команду может выполнять только root. В Ubuntu 24.04 этот параметр по умолчанию равен 1, и без прав администратора dmesg отвечает dmesg: read kernel buffer failed: Operation not permitted; там журнал ядра читают командой sudo dmesg или journalctl -k (пользователю из группы adm она доступна без sudo). В среде, где получены примеры ниже (WSL2), ограничения нет.

dmesg -x --level=err,warn | head -4

kern  :warn  : [    0.143513] Speculative Return Stack Overflow: IBPB-extending microcode not applied!
kern  :warn  : [    0.143513] Speculative Return Stack Overflow: WARNING: See https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html for mitigation options.
kern  :err   : [    0.184144] PCI: Fatal: No config space access function found
kern  :warn  : [    0.216104] PCI: System does not support PCI

Предупреждения здесь не говорят о неисправности: WSL2 запускает ядро в виртуальной машине без реальной шины PCI. Это пример того, что сообщение уровня err надо читать, а не пугаться его. Опция -T в WSL2 и в виртуальных машинах может показать неверное время, так как пересчитывает время запуска ядра, а оно расходится с часами после приостановки машины; справочная страница прямо предупреждает, что результат может быть неточным. Надёжнее ориентироваться на секунды от запуска ядра.

Если в системе работает systemd, те же сообщения читает и journalctl -k (то есть --dmesg): преимущество в том, что журнал journald хранит их на диске, между перезагрузками, и позволяет применять уже знакомые фильтры -b, --since и -p ⁴. В WSL2 без systemd команда возвращает -- No entries --, поэтому там остаётся dmesg.

OOM-killer: что происходит при нехватке памяти

Ядро по умолчанию выдаёт процессам памяти больше, чем есть на самом деле: большинство программ запрашивают с запасом и используют лишь часть. Это называется перераспределением (англ. overcommit), режим задаётся файлом /proc/sys/vm/overcommit_memory. Пока процессы трогают страницы лишь изредка, схема работает. Когда они начинают реально использовать больше, чем есть оперативной памяти и подкачки, ядро не может ни выделить, ни ждать вечно. Тогда запускается OOM-killer (англ. out-of-memory killer): код ядра, который выбирает процесс и принудительно завершает его сигналом SIGKILL. Из состояния «нет памяти» это единственный выход, который сохраняет остальную систему живой ³.

Жертву выбирают по числу oom_score, которое ядро вычисляет для каждого процесса. Главный вклад — доля памяти процесса (резидентная, подкачанная и память под таблицы страниц) от общего объёма: чем больше процесс занимает, тем выше балл, максимум 1000. К расчёту прибавляется поправка oom_score_adj, число от -1000 до 1000, которое можно менять. Положительное значение делает процесс более вероятной жертвой, отрицательное защищает, а -1000 полностью исключает его из выбора. Оба значения доступны в /proc/PID/.

cat /proc/self/oom_score /proc/self/oom_score_adj

666
0

В этой среде у любого процесса базовый балл равен 666: он зависит от настроек WSL2 и других ядер может быть иным, поэтому важны относительные изменения. Покажем их. Запустим процесс, занимающий 400 МБ, затем изменим поправку.

python3 -c "
import os, time
b = bytearray(400*1024*1024)
for i in range(0, len(b), 4096): b[i] = 1
print(os.getpid(), flush=True); time.sleep(30)" > pid.txt &
sleep 2.5
P=$(cat pid.txt)
grep VmRSS /proc/$P/status
cat /proc/$P/oom_score /proc/$P/oom_score_adj
echo 300 > /proc/$P/oom_score_adj
cat /proc/$P/oom_score /proc/$P/oom_score_adj
echo -1000 > /proc/$P/oom_score_adj

VmRSS:	  418176 kB
694
0
894
300
bash: echo: write error: Permission denied

Занятые 400 МБ добавили к базовому баллу 28 единиц, поправка +300 — ровно 300. Обычный пользователь может повышать oom_score_adj своих процессов, то есть назначать их жертвами, но не понижать: для отрицательного значения нужны права root (или возможность CAP_SYS_RESOURCE). Это то же правило асимметрии, что и у nice выше: добровольно уступить можно, захватить больше нельзя.

Следы работы OOM-killer остаются в журнале ядра. Ищите две строки: invoked oom-killer называет процесс, чей запрос памяти вызвал срабатывание, а Out of memory: Killed process называет жертву с её размером. В этой среде срабатываний не было и поиск не находит ничего (код возврата 1 означает «совпадений нет»):

dmesg | grep -iE 'out of memory|killed process'
echo "код возврата: $?"

код возврата: 1

Реально исчерпать память машины в учебных целях не нужно, поэтому типичные записи приводятся по документации. Ниже пример вывода (не получен в этой среде).

[ 8123.456789] python3 invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
[ 8123.457102] Mem-Info:
[ 8123.457300] Out of memory: Killed process 4242 (python3) total-vm:9437184kB, anon-rss:7340032kB, file-rss:1024kB, shmem-rss:0kB, UID:1000 pgtables:14500kB oom_score_adj:0

Здесь жертвой стал процесс 4242 с резидентной анонимной памятью около 7 ГБ. Со стороны пользователя это выглядит так: программа внезапно исчезает без собственного сообщения, оболочка пишет Killed, а код возврата равен 137 (128 плюс номер сигнала 9, см. раздел о кодах возврата). Если рядом шла работа нескольких процессов, первое подозрение при необъяснимом Killed — OOM-killer; проверяют его командой dmesg -T | grep -i 'killed process' или journalctl -k | grep -i 'killed process'.

Предел памяти можно задать и группе процессов, а не всей машине. Тогда срабатывает та же логика, но в пределах группы: в журнале появляется строка Memory cgroup out of memory, а остальные процессы системы не страдают. Так работают лимиты контейнеров и systemd-run -p MemoryMax=; подробно — в теме 12.

Пределы ресурсов: ulimit, prlimit и limits.conf

Помимо общей нехватки ресурсов, ядро ограничивает каждый процесс отдельно. Предел (англ. resource limit) задаёт, сколько открытых файлов, процессов, памяти или процессорного времени процесс может использовать. У каждого предела два значения: мягкий (англ. soft) действует прямо сейчас, а жёсткий (англ. hard) — потолок, выше которого мягкий предел поднять нельзя. Обычный пользователь может свободно менять мягкий предел в пределах жёсткого и необратимо понижать жёсткий; повысить жёсткий предел может только root. Пределы наследуются: дочерний процесс при fork получает копию пределов родителя и не может превысить их ³.

Встроенная команда оболочки ulimit показывает и меняет пределы текущей оболочки и всех процессов, которые она запустит. Основные опции: -a показать всё, -n число открытых файлов, -u число процессов пользователя, -v виртуальная память в килобайтах, -c размер файла дампа памяти (core), -S и -H выбирают мягкий и жёсткий предел. Без -S и -H при установке значения меняются оба предела, а при чтении показывается мягкий ⁶.

ulimit -Sn; ulimit -Hn
ulimit -u; ulimit -c; ulimit -v

1048576
1048576
31621
0
unlimited

Лимит файлов здесь необычно велик; в классическом дистрибутиве мягкий предел равен 1024. Размер дампа памяти -c равен нулю: при аварии файл core не создаётся. Разработчики включают его командой ulimit -c unlimited, чтобы разбирать падения.

Лучше всего предел -n виден на программе, которая открывает файлы без закрытия. Ниже учебный скрипт openmany.py делает это в цикле, пока не получит ошибку, а предел снижен в подоболочке до 64.

bash -c 'ulimit -n 64; python3 openmany.py; echo "код: $?"'

открыто 61 файлов, затем: [Errno 24] Too many open files: '/dev/null'
код: 1

Из 64 дескрипторов три уже заняты стандартными потоками, поэтому открыть удалось 61. «Too many open files» (ошибка EMFILE, номер 24) — типичная авария сетевых серверов: каждое соединение занимает дескриптор, и при мягком пределе 1024 сервер перестаёт принимать клиентов. Поэтому серверам повышают предел -n, но только в пределах жёсткого. Проверим правила мягкого и жёсткого пределов и наследование.

bash -c 'ulimit -Sn 100; ulimit -Hn 200
         bash -c "ulimit -Sn; ulimit -Hn; ulimit -Sn 150; ulimit -Sn; ulimit -Sn 300"'
bash -c 'ulimit -n 200; ulimit -Hn 400'

100
200
150
bash: line 1: ulimit: open files: cannot modify limit: Invalid argument
bash: line 1: ulimit: open files: cannot modify limit: Operation not permitted

Внутренняя оболочка унаследовала мягкий 100 и жёсткий 200. Подняв мягкий до 150, она получила отказ при попытке выйти за жёсткие 200 (ошибка «Invalid argument»). Во втором примере ulimit -n 200 без -S и -H понизил оба предела, и повышение жёсткого до 400 запрещено («Operation not permitted»). Вывод: понизить предел можно командой, вернуть назад — только запуском новой оболочки с прежними пределами, поэтому осторожные эксперименты проводят в подоболочке с bash -c или в круглых скобках.

Команда ulimit действует на себя и будущих потомков. Чтобы увидеть пределы чужого процесса, читают файл /proc/PID/limits, а изменить их на лету позволяет утилита prlimit (она входит в пакет util-linux; подробнее в справочной странице prlimit(1)).

sleep 500 &
P=$!
prlimit --pid $P --nofile
prlimit --pid $P --nofile=512:1024
grep 'open files' /proc/$P/limits

RESOURCE DESCRIPTION                 SOFT    HARD UNITS
NOFILE   max number of open files 1048576 1048576 files
Max open files            512                  1024                 files     

Формат --nofile=мягкий:жёсткий задаёт оба значения; понижать пределы работающего процесса обычный пользователь может, повышать жёсткий — нет. ulimit в оболочке действует до её закрытия. Постоянные пределы для пользователей задаются в файле /etc/security/limits.conf и в каталоге /etc/security/limits.d/, которые читает PAM-модуль pam_limits при входе. Строка файла имеет формат «кому, тип, предел, значение», например:

student   soft   nofile   4096
student   hard   nofile   65536
@dev      -      nproc    2048

Первая колонка — имя пользователя, группа с префиксом @ или * для всех; вторая — soft, hard или - (оба); третья — название предела (nofile, nproc, core, as и другие); четвёртая — значение. В этой среде файл содержит только комментарии. Строки вступают в силу при следующем входе в систему и касаются сеансов, открытых через PAM; службы systemd эти файлы не читают, а задают пределы директивами LimitNOFILE= и подобными в юнит-файле (тема 9). Администратору удобно запомнить порядок проверки: что показывает /proc/PID/limits у проблемного процесса, оттуда ли значение (оболочка, limits.conf или юнит), и только потом менять настройку.

Итоги темы

Процесс — это выполняющаяся программа с номером, родителем, состоянием и набором открытых файлов. Оболочка создаёт процессы через fork и exec и ждёт их через wait; код возврата лежит в основе операторов && и || из темы 5. Состояния R, S, D, T и Z показывают, чем занят процесс: зомби ждёт, пока родитель его заберёт, остановленный процесс ждёт fg или SIGCONT.

Сигналы — основной инструмент управления процессами. SIGTERM даёт программе возможность завершиться аккуратно, SIGINT и SIGTSTP отвечают на действия пользователя, SIGHUP связывает процесс с терминалом. SIGKILL и SIGSTOP нельзя перехватить, поэтому их применяют только в крайнем случае. Управление заданиями строится на тех же сигналах.

Ресурсы процесса контролируются отдельно. Команды lsof и каталог /proc/PID/fd показывают открытые файлы и сокеты, включая удалённые, но ещё занятые файлы; watch позволяет наблюдать за изменением состояния; журнал ядра dmesg хранит сообщения, которые некому принять раньше, чем запустятся остальные службы. При нехватке памяти OOM-killer завершает процесс с наибольшим oom_score, а следы остаются в журнале ядра. Пределы ulimit (мягкий и жёсткий) ограничивают число файлов, процессов и объём памяти; они наследуются потомками, а их постоянные значения задаются в limits.conf или в юнит-файле.

Тема подготовила почву для следующих. Службы, которые должны работать постоянно и переживать перезагрузку, описываются в теме 9 средствами systemd. Переменные окружения, которые наследуются дочерними процессами, рассмотрены в теме 8. Для курса «Компьютерные сети» знания о процессах, сигналах и зомби нужны при работе с сетевыми серверами и при диагностике зависших программ.

Литература

1. Ritchie D. M., Thompson K. The UNIX Time-Sharing System. — Communications of the ACM, 1974, Vol. 17, No. 7, С. 365–375, DOI: 10.1145/361011.361061.
2. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019. Открытая версия: https://linuxcommand.org/tlcl.php
3. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
4. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
5. Free Software Foundation. GNU Coreutils Manual. — https://www.gnu.org/software/coreutils/manual/
6. Free Software Foundation. GNU Bash Reference Manual. — https://www.gnu.org/software/bash/manual/
7. The Linux man-pages project. — https://man7.org/linux/man-pages/
8. The Open Group. The Open Group Base Specifications Issue 7 (IEEE Std 1003.1-2017), Shell Command Language. — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

Дополнительные материалы

Вопросы для самопроверки

1. Чем программа отличается от процесса? Сколько процессов может быть запущено из одного исполняемого файла /usr/bin/sleep?
2. Какие два системных действия использует оболочка для запуска команды? Какой процесс выполняет wait, и что он получает от ребёнка?
3. Что означают буквы R, S, D, T и Z в колонке STAT? Почему процесс в состоянии D не реагирует даже на SIGKILL?
4. Почему kill -KILL не устраняет зомби? Какое действие действительно убирает зомби из таблицы процессов?
5. Чем сирота отличается от зомби? Кто становится родителем осиротевшего процесса?
6. Почему SIGTERM предпочтительнее SIGKILL? Какие сигналы не могут быть перехвачены программой и почему это сделано?
7. Что делает Ctrl+Z? Чем остановленное задание отличается от фонового по состоянию процесса?
8. Почему фоновое задание может погибнуть при закрытии терминала? Чем disown отличается от nohup?
9. Как понизить приоритет процесса с помощью renice? Почему обычный пользователь не может повысить приоритет?
10. Что означает load average, равный 12, в системе с двенадцатью ядрами? Какие процессы учитываются в этом значении?
11. Почему $! после команды cd каталог && программа & может указывать на подоболочку, а не на программу?
12. Что показывает колонка available в выводе free -h? Почему низкое значение free само по себе не говорит о нехватке памяти?
13. Чем watch -n 1 -d 'команда' отличается от tail -f и когда он удобнее?
14. Что показывает ls -l /proc/PID/fd и чем lsof -p PID дополняет этот вывод? Как с помощью lsof -i :порт найти владельца порта?
15. Почему после удаления большого журнала командой rm место на диске не освободилось? Как это видно в lsof +L1 и в /proc?
16. Зачем ядру собственный журнал и чем dmesg отличается от journalctl -k? Почему время по dmesg -T может быть неточным?
17. Когда срабатывает OOM-killer и как он выбирает жертву? Как найти его след в журнале и какой код возврата получит оболочка?
18. Чем мягкий предел ресурса отличается от жёсткого? Какие пределы можно менять обычному пользователю и как предел наследуется потомками?

Глоссарий темы

Шпаргалка

Наблюдение:

ps aux                                  # все процессы, стиль BSD
ps -ef                                  # все процессы, стиль System V
ps -eo pid,ppid,stat,comm,args          # выбранные колонки
ps aux --sort=-%cpu | head -5           # самые загруженные по процессору
ps aux --sort=-rss | head -5            # самые большие по памяти
pstree -p                               # дерево процессов
pgrep -a имя                            # PID и командная строка по имени
top -b -n1 | head -12                   # пакетный снимок top
cat /proc/PID/status                    # состояние и владелец процесса
tr '\0' ' ' < /proc/PID/cmdline; echo   # командная строка процесса

Сигналы и завершение:

kill PID                                # SIGTERM (по умолчанию)
kill -KILL PID                          # SIGKILL: нельзя перехватить
kill -l                                 # список сигналов
kill -0 PID                             # проверка существования процесса
pkill -x имя                            # по точному имени
killall имя                             # по имени, все процессы с этим именем

Ресурсы, открытые файлы и журнал ядра:

watch -n 1 -d 'ps -o pid,stat,comm -p PID'  # повторять команду, подсвечивать изменения
ls -l /proc/PID/fd                      # дескрипторы процесса
lsof -p PID                             # открытые файлы процесса
lsof -i :8080                           # кто занял порт
lsof +D каталог                         # кто держит файлы в каталоге
lsof +L1                                # удалённые, но открытые файлы
fuser -v файл                           # процессы, использующие файл
dmesg -T -l err,warn                    # журнал ядра: ошибки и предупреждения
journalctl -k -b                        # журнал ядра через journald
dmesg | grep -i 'killed process'        # след OOM-killer
cat /proc/PID/oom_score /proc/PID/oom_score_adj
ulimit -a ; ulimit -Sn ; ulimit -Hn     # пределы оболочки
ulimit -Sn 4096                         # поднять мягкий предел файлов в пределах жёсткого
prlimit --pid PID --nofile              # пределы чужого процесса
cat /proc/PID/limits                    # текущие пределы процесса

Задания и приоритеты:

команда &                               # запуск в фоне
jobs -l                                 # список заданий с PID
fg %2 ; bg %2                           # передний план; фон
Ctrl+Z ; Ctrl+C                         # остановка (SIGTSTP); прерывание (SIGINT)
nohup команда &                         # защита от SIGHUP, вывод в nohup.out
disown %1                               # убрать задание из таблицы оболочки
nice -n 10 команда                      # запуск с пониженным приоритетом
renice -n 5 -p PID                      # изменить приоритет работающего процесса
uptime ; free -h                        # загрузка и память

Типичные ошибки

Что почитать и посмотреть

1. Shotts W. The Linux Command Line, главы о процессах и управлении заданиями — https://linuxcommand.org/tlcl.php. Просто изложенные примеры команд ps, kill, jobs с реальным выводом.
2. Справочная страница signal(7) — https://man7.org/linux/man-pages/man7/signal.7.html. Полная таблица сигналов, действия по умолчанию и правила для SIGKILL и SIGSTOP.
3. Справочная страница proc(5) — https://man7.org/linux/man-pages/man5/proc.5.html. Описание файлов /proc/<pid>/: status, cmdline, fd, exe.
4. GNU Bash Reference Manual, раздел «Job Control» — https://www.gnu.org/software/bash/manual/. Точное описание фоновых заданий, fg, bg, jobs и disown.
5. GNU Coreutils Manual — https://www.gnu.org/software/coreutils/manual/. Разделы о nice, nohup и timeout.
6. Kerrisk M. The Linux Programming Interface — книга для тех, кто хочет понять fork, exec, wait и сигналы на уровне системных вызовов.
7. explainshell.com — вставьте строку команды, например ps -eo pid,ppid,stat,args, и получите объяснение каждого флага.
8. OverTheWire Bandit — учебная игра по командной строке; она не посвящена процессам, но тренирует уверенную работу в терминале, на которой строится вся тема.

Лабораторная работа 7. Процессы и управление заданиями

• Раздел курса: тема 7 «Процессы и управление заданиями»

Введение

В теории темы 7 процесс описан как выполняющаяся программа с номером, родителем и состоянием, а сигнал — как способ управлять процессом извне. В этой работе эти понятия проверяются на практике: запускаются учебные программы из окружения, их состояние наблюдается в ps, top и каталоге /proc, им посылаются сигналы, создаётся и устраняется зомби, отыскивается процесс, занявший процессор, и исправляется ошибка в команде, которая отправляет сигнал не тому процессу.

В продвинутых частях дополнительно разбираются открытые файлы и пределы ресурсов процесса: ищется процесс, держащий удалённый файл, воспроизводится ошибка «Too many open files» и показывается, как найти след OOM-killer в журнале ядра.

Работа состоит из основной (базовой) части (части 1–6) и продвинутой (углублённой, по желанию) части (части 7–8).

Цель работы

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

После выполнения работы получится:

• определить по выводу ps и /proc/<pid>/ состояние процесса, его родителя и командную строку;
• предсказать реакцию программы на сигналы SIGHUP, SIGTERM, SIGINT, SIGTSTP, SIGCONT, SIGKILL и SIGSTOP и проверить предсказание;
• управлять фоновыми заданиями командами jobs, fg, bg, клавишами Ctrl+Z и Ctrl+C;
• найти зомби-процесс, объяснить его происхождение и устранить, завершив родителя;
• найти процесс, занимающий процессор, с помощью top и ps и завершить его;
• найти ошибку в команде, которая посылает сигнал фоновому процессу, и исправить её;
• (продвинутая часть) найти по lsof и /proc/PID/fd процесс, держащий удалённый файл, и освободить место;
• (продвинутая часть) вызвать и устранить ошибку «Too many open files» изменением ulimit -n, объяснить мягкий и жёсткий предел;
• (продвинутая часть) найти в журнале ядра следы OOM-killer, не исчерпывая память машины.

Теоретический минимум

Необходимый материал изложен в теории темы 7: разделы «Программа и процесс», «Состояния процессов», «Сигналы» и «Управление заданиями в интерактивной оболочке». Пожиратель CPU и зомби в работе создаются учебными программами, поэтому правила их устройства приведены в файле README.md окружения.

Учебные программы окружения:

Перечень оснащения

• Ubuntu 24.04 или Ubuntu в WSL2.
• Утилиты ps, top, pgrep, pstree и killall. Проверка: which ps top pgrep pstree killall. При отсутствии установите пакеты: sudo apt install procps psmisc (команда требует прав администратора).
• Архив окружения lr-env: учебные программы и описание в README.md.

Порядок выполнения работы

Архив распаковать и перейти в рабочий каталог скриптов:

unzip ~/Downloads/lr-env.zip -d ~/lab-07 && cd ~/lab-07/lr-env

Все команды выполнять в одной оболочке Bash, чтобы номера заданий (%1, %2) не менялись. PID фонового процесса сохранять сразу после запуска: P=$!.

Для каждой команды, отмеченной «предсказание», перед запуском записать ожидаемый результат. После запуска записать фактический результат и объяснить расхождение, если оно есть. Формат записи: команда — предсказание — результат — объяснение. Учебные процессы, которые не нужны, завершать и проверять, что после работы не осталось лишних процессов.

Часть 1. Дерево процессов и /proc

Задание

1. Запустить два фоновых процесса sleep 1001 и sleep 1002 и вывести дерево процессов текущей оболочки:

sleep 1001 &
P1=$!
sleep 1002 &
pstree -p $$

Предсказание: какие процессы будут дочерними оболочки; какой процесс будет родителем pstree.

2. Вывести состояние, родителя и командную строку процесса sleep 1001. PID взять из переменной P1, сохранённой сразу после запуска (переменная $! к этому моменту уже указывает на sleep 1002):

ps -o pid,ppid,pgid,stat,comm,args -p "$P1"

Предсказание: значение колонки STAT у спящего процесса; значение PPID.

3. Прочитать сведения о процессе из /proc:

grep -E '^(Name|State|PPid|Uid):' /proc/$P1/status
tr '\0' ' ' < /proc/$P1/cmdline; echo
ls -l /proc/$P1/fd

Предсказание: что покажет cmdline и какие открытые файлы будут у процесса (0, 1, 2).

4. Завершить оба процесса командой kill и проверить, что они исчезли.

Что должно получиться

В журнале работы: дерево процессов; значения колонок PID, PPID, STAT и COMMAND для процесса sleep 1001; содержимое cmdline и список потоков в fd. Объяснить, почему PPID процесса равен PID оболочки, а колонка STAT содержит букву S.

Часть 2. Фоновые задания и управление ими

Задание

1. Запустить worker.sh в фоне и посмотреть список заданий:

cd ~/lab-07/lr-env
./worker.sh &
jobs -l

2. Переместить задание на передний план командой fg %1, дождаться трёх строк времени и нажать Ctrl+Z. Предсказание: какой текст выведет оболочка и каким станет состояние задания по колонке STAT процесса.

3. Выполнить jobs, затем вернуть задание в фон командой bg %1. Проверить, что время продолжает печататься, но приглашение доступно.

4. Вернуть задание на передний план командой fg %1 и прервать его клавишами Ctrl+C. Предсказание: будет ли выведено сообщение worker.sh о завершении.

5. Запустить worker.sh снова, в фоне, и остановить его командой kill -TSTP %1. Затем продолжить командой kill -CONT %1. Сравнить вывод ps -o stat в обоих случаях.

Что должно получиться

В журнале работы: последовательность состояний задания (фон, остановлено, передний план), вывод jobs после каждого шага, значение STAT в состояниях T и S. Объяснить, почему после Ctrl+C сообщение worker.sh не появилось (процесс получил SIGINT, для которого в worker.sh нет обработчика).

Часть 3. Сигналы: предсказать реакцию

Задание

Для каждого сигнала из таблицы записать предсказание, затем запустить worker.sh в фоне, отправить сигнал командой kill -СИГНАЛ $P и проверить результат по выводу и по ps -o stat -p $P. После проверки каждого сигнала перезапускать worker.sh, если процесс завершился.

Код возврата процесса, завершённого сигналом, можно получить командой wait $P; echo $? в той же оболочке. Для процессов, которые были запущены через &, эта команда работает только в той же оболочке.

Дополнительный вопрос: почему worker.sh не может перехватить SIGKILL, и что меняется в выводе, если его отправить вместо SIGTERM.

Что должно получиться

Таблица, заполненная предсказаниями и фактами, и вывод по каждому сигналу. Отдельно объяснить, почему для SIGTERM код возврата равен 0, а для SIGKILL — 137. Указать, какие сигналы могут быть перехвачены программой, а какие нет.

Часть 4. Зомби: найти и устранить

Задание

1. Запустить zombie.py в фоне с временем 600 секунд и сохранить PID родителя:

python3 zombie.py 600 &
P=$!
sleep 1

2. Найти дочерний процесс в состоянии Z. Команда:

ps -eo pid,ppid,stat,comm | awk '$3 ~ /Z/'

Предсказание: PPID зомби совпадёт с $P; в колонке COMMAND будет отметка <defunct>.

3. Попробовать устранить зомби сигналом: kill -KILL PID_ЗОМБИ. Предсказание: исчезнет ли процесс из таблицы, и что вернёт kill. Проверить ps -o pid,stat,comm -p PID_ЗОМБИ.

4. Устранить зомби, завершив родителя: kill -TERM $P, затем повторить поиск зомби. Предсказание: кто заберёт зомби после завершения родителя.

5. Проверить, что родитель, то есть zombie.py, завершился, и что процессов в состоянии Z не осталось.

Что должно получиться

В журнале работы: строка таблицы процессов с зомби, ответ на вопрос, почему kill -KILL не устранил зомби, и объяснение того, кто забрал зомби после гибели родителя. В объяснении использовать понятия «родитель», «wait()», «процесс-приёмный родитель» (процесс 1 или его аналог в WSL2).

Часть 5. Пожиратель CPU: найти и завершить

Задание

1. Запустить два процесса worker.sh в фоне (они нагружают процессор слабо) и один процесс cpu_hog.sh на 600 секунд:

./worker.sh > /dev/null 2>&1 &
./worker.sh > /dev/null 2>&1 &
./cpu_hog.sh 600 &
H=$!
sleep 2

2. Найти процесс, занимающий процессор. Команды:

top -b -n1 | head -12
ps -eo pid,pcpu,stat,args --sort=-pcpu | head -5

Предсказание: какой процесс окажется первым и в каком состоянии (R или S). Значение $H должно совпасть с PID в первой строке.

3. Записать загрузку системы командой cat /proc/loadavg и значение load average через минуту, при работе cpu_hog.sh. Предсказание: как изменится первое число по сравнению с исходным значением.

4. Понизить приоритет процесса cpu_hog.sh командой renice -n 19 -p $H. Предсказание: изменится ли доля процессора на системе с несколькими ядрами, если других занятых процессов мало. Проверить командой ps -o pid,ni,pcpu,args -p $H.

5. Завершить cpu_hog.sh командой kill $H. Затем завершить оба worker.sh, проверив их PID командой ps -eo pid,args | grep "[w]orker".

Что должно получиться

В журнале работы: строка top или ps с процессом-пожирателем, значение NI до и после renice, загрузка процессора до и после. Объяснить, почему первым процессом в ps --sort=-pcpu оказался именно cpu_hog.sh, и почему его командная строка видна в колонке args, а в колонке comm стоит bash.

Часть 6. Найти и исправить ошибку

Задание

Даны команды, которые должны были остановить фоновый процесс worker.sh, но не сделали этого. Ошибка есть в одной строке. Порядок работы:

1. Выполнить в оболочке следующие команды:

cd ~/lab-07/lr-env && ./worker.sh > worker.log 2>&1 &
sleep 2
kill -TERM $!
sleep 1
ps -eo pid,ppid,stat,args | grep "[w]orker"
tail -2 worker.log

Предсказание: завершится ли процесс worker.sh, появится ли в журнале сообщение о SIGTERM.

2. Проверить результат. Для объяснения вывести PID, который хранит $! и сравнить его с колонкой ARGS.

3. Найти ошибку. Указание: переменная $! содержит PID последнего фонового процесса. Для команды cd … && ./worker.sh … & фоновой становится вся цепочка, и $! указывает на подоболочку, которая запускает worker.sh, а не на сам worker.sh.

4. Исправить команду так, чтобы $! указывал на worker.sh: сначала перейти в каталог отдельной командой, затем запустить программу в фоне:

cd ~/lab-07/lr-env
./worker.sh > worker.log 2>&1 &
W=$!
sleep 2
kill -TERM "$W"
wait "$W"; echo "код: $?"

Предсказание: код возврата и сообщение в журнале.

5. Убедиться, что процесс, который не был остановлен в первом варианте, завершён (при необходимости завершить его по PID из колонки PID).

Что должно получиться

В журнале работы: исходная команда, объяснение ошибки (что такое фоновая подоболочка и почему $! указывает на неё), исправленная команда и вывод, подтверждающий завершение worker.sh с кодом 0.

Часть 7. Отрыв от терминала и загрузка системы (продвинутая)

Задание

1. Во вложенной оболочке bash (команда bash, а не текущая оболочка терминала) запустить три процесса sleep: sleep 1401 & (обычный фон), sleep 1402 & с последующей командой disown %2 и nohup sleep 1403 >/dev/null 2>&1 &. Записать предсказание: какие процессы переживут SIGHUP, если отправить его этой вложенной оболочке командой kill -HUP $$.

2. Проверить результат в основной оболочке командой pgrep -a -x sleep, после того как вложенная оболочка завершилась. Объяснить, почему disown и nohup дают разный результат.

3. Записать значения uptime и cat /proc/loadavg, запустить cpu_hog.sh 60 в фоне, через 30 секунд повторить запись. Объяснить изменение трёх чисел load average.

4. Записать free -h, затем прочитать большой файл, например cat /usr/bin/* > /dev/null, и снова записать free -h. Объяснить, почему колонка free уменьшилась, колонка buff/cache выросла, а колонка available почти не изменилась.

Что должно получиться

В журнале работы: таблица «процесс — способ запуска — выжил ли после SIGHUP», значения load average и объяснение их изменения, вывод free -h и объяснение колонок free и available.

Часть 8. Открытые файлы, пределы и журнал ядра (продвинутая)

Задание

1. Запишите предсказание и выполните в одной оболочке: exec 7>deleted.log, echo данные >&7, rm deleted.log. Найдите дескриптор двумя способами: ls -l /proc/$$/fd/7 и lsof +L1 -a -p $$. Объясните пометку (deleted) и колонку NLINK. Выполните cat /proc/$$/fd/7 и посмотрите, можно ли прочитать «потерянные» данные; затем освободите место командой exec 7>&-.

2. Запустите python3 -m http.server 8765 --bind 127.0.0.1 >/dev/null 2>&1 &. Определите по lsof -i :8765 его PID, а по lsof -p PID — текущий каталог и исполняемый файл. Попробуйте запустить второй сервер на том же порту и объясните сообщение об ошибке. Завершите сервер.

3. Запустите watch -n 1 -d 'ps -o pid,stat,etime,comm -p PID' для процесса worker.sh, во втором окне терминала отправьте ему kill -STOP, затем kill -CONT, и наблюдайте за изменением колонки STAT. Остановите watch клавишами Ctrl+C. Запишите, какие символы подсветил -d.

4. Запишите значения ulimit -Sn и ulimit -Hn. Выполните bash -c 'ulimit -n 64; python3 openmany.py; echo "код: $?"'; предскажите число открытых файлов до запуска. Затем выполните bash -c 'ulimit -Sn 128; ulimit -Hn 256; python3 openmany.py', и объясните, почему результат определяется мягким, а не жёстким пределом. Проверьте, что попытка поднять мягкий предел выше жёсткого завершается ошибкой: bash -c 'ulimit -Sn 128; ulimit -Hn 256; ulimit -Sn 300; echo "код: $?"' (каждый новый процесс bash -c наследует исходные пределы, поэтому жёсткий предел 256 нужно установить в той же команде, а мягкий понизить заранее: жёсткий нельзя сделать меньше текущего мягкого).

5. Найдите и исправьте ошибку. Администратор хотел временно ограничить скрипт 64 файлами, а потом вернуть 4096, и написал bash -c 'ulimit -n 64; ulimit -n 4096; python3 openmany.py', ожидая, что откроется около 4000 файлов. Запустите, объясните отказ (без -S и -H команда ulimit -n 64 понизила оба предела, а жёсткий предел обычный пользователь повысить не может). Исправьте команду так, чтобы понижался только мягкий предел (ulimit -Sn 64), и проверьте, что второй вызов ulimit -Sn 4096 теперь выполняется и openmany.py открывает около 4000 файлов.

6. Запустите sleep 600 & и сравните /proc/PID/limits до и после prlimit --pid PID --nofile=256:512. Определите oom_score и oom_score_adj этого процесса, затем повысьте поправку командой echo 500 > /proc/PID/oom_score_adj и убедитесь, что oom_score вырос. Попробуйте записать -500; объясните отказ.

7. Выполните dmesg -x --level=err,warn | head (если dmesg отвечает Operation not permitted, как в Ubuntu 24.04 с kernel.dmesg_restrict=1, используйте sudo dmesg или journalctl -k) и найдите уровень, подсистему и время одной записи. Затем выполните dmesg | grep -iE 'out of memory|killed process' и объясните код возврата. Не вызывайте нехватку памяти реально: по описанию в теории запишите, по каким двум строкам журнала ядра отличают работу OOM-killer, и какой код возврата получит оболочка у убитой программы.

Что должно получиться

В журнале работы: вывод lsof +L1 с пометкой (deleted) и объяснение, почему место на диске освобождается только после закрытия дескриптора; PID процесса, занявшего порт 8765, и текст ошибки второго запуска; число файлов, открытых openmany.py при каждом пределе, и объяснение разницы между мягким и жёстким; исправленная команда пункта 5; значения oom_score до и после изменения поправки; строки журнала ядра для пункта 7.

Журнал работы

Для себя ведите записи в порядке «предсказание — команда — фактический вывод — объяснение расхождения». Выводы команд сохраняйте полностью, а не пересказывайте. В конце отметьте, что оказалось неожиданным и как вы это проверили.

Контрольные вопросы

1. Чем программа отличается от процесса? Сколько процессов может иметь одна программа sleep?
2. Какие два системных действия использует оболочка, чтобы запустить программу, и что делает родитель, пока ребёнок работает?
3. Что означают буквы R, S, D, T и Z в колонке STAT? Какое состояние процесса нельзя прервать сигналом?
4. Почему зомби нельзя устранить командой kill -KILL, и что нужно сделать для его устранения?
5. Что такое сирота и кто становится его родителем?
6. Почему сигнал SIGTERM предпочтительнее SIGKILL, и какие сигналы программа не может перехватить?
7. Что делает Ctrl+Z и чем отличается остановленное задание от фонового?
8. Почему при закрытии терминала фоновые задания могут завершиться, и как nohup и disown предотвращают это?
9. Что показывает колонка NI, и может ли обычный пользователь повысить приоритет процесса?
10. Как по выводу uptime определить, перегружена ли система с двенадцатью ядрами, если load average равен 12?
11. Почему $! после команды cd … && ./программа & может указывать не на программу, а на подоболочку?
12. Что показывает колонка available в выводе free -h и почему она важнее колонки free?
13. Почему после rm большого журнала свободное место на диске не увеличилось, и как найти виноватый процесс?
14. Чем мягкий предел отличается от жёсткого? Может ли обычный пользователь поднять жёсткий предел, и что происходит с пределами дочернего процесса?
15. Как OOM-killer выбирает жертву? Что означают oom_score и oom_score_adj и какие записи в журнале ядра указывают на его работу?