Введение
Работающая система Linux — это не только файлы. Ядро управляет оборудованием и процессами, каждая команда выполняется как процесс со своим идентификатором, а оболочка отслеживает задания переднего и фонового плана. Администраторы сначала наблюдают за состоянием системы, а затем воздействуют на минимально необходимый процесс.
В этой лабораторной работе вы определите операционную систему и ядро, интерпретируете время работы и средние значения нагрузки, исследуете связи между процессами, найдёте процессы по имени, отправите сигналы завершения, попрактикуетесь в интерактивном управлении заданиями, интерпретируете код завершения, запустите отсоединённую команду с помощью nohup и прочитаете последние сообщения ядра.
Определите систему и интерпретируйте нагрузку
На этом шаге вы определите ядро и дистрибутив, проверите, как долго работает система, и узнаете, что означают средние значения нагрузки.
Создайте рабочий каталог и перейдите в него:
mkdir -p /home/labex/project/process-lab
cd /home/labex/project/process-lab
Команда uname выводит сведения о ядре. Параметры -s, -r и -m выбирают имя ядра, его выпуск и архитектуру машины:
uname -srm
Команда uname -a выводит все доступные поля в одной строке:
uname -a
Ядро — не то же самое, что дистрибутив Linux. Прочитайте метаданные дистрибутива:
cat /etc/os-release
Найдите такие поля, как NAME, VERSION и ID. Затем проверьте время работы системы и нагрузку:
uptime
Вывод содержит текущее время, продолжительность работы системы, количество вошедших в систему пользователей и три средних значения нагрузки. Эти значения описывают выполняемую или не прерываемую работу примерно за 1, 5 и 15 минут. Это не проценты: их смысл частично зависит от количества ядер процессора.
Просмотрите компактную запись о нагрузке ядра:
cat /proc/loadavg
Первые три значения соответствуют средним значениям нагрузки. Следующие поля показывают выполняемые задачи и последний назначенный идентификатор процесса.
Сохраните краткую сводку о системе для дальнейшего использования:
uname -srm > system-summary.txt
uptime >> system-summary.txt
cat system-summary.txt
В файле должны находиться одна строка со сведениями о ядре и одна строка со сведениями о времени работы системы.
Исследуйте процессы и активность ресурсов
На этом шаге вы исследуете идентификаторы процессов, связи с родительскими процессами, состояния процессов и снимок активности системных ресурсов.
Процесс — это выполняющаяся программа. У каждого процесса есть идентификатор процесса, или PID. У большинства процессов также есть идентификатор родительского процесса, или PPID. Он указывает на процесс, который запустил данный процесс.
Команда ps выводит снимок процессов. Выберите полезные поля и отсортируйте их по PID:
cd /home/labex/project/process-lab
ps -eo pid,ppid,user,stat,comm --sort=pid | head -n 15
Параметр -e выбирает все процессы, а -o определяет столбцы:
PID— идентификатор процесса.PPID— идентификатор родительского процесса.USER— владелец процесса.STAT— состояние процесса и дополнительные флаги.COMMAND— имя исполняемого файла.
К распространённым буквам состояния относятся R — выполняется, S — прерываемый сон, D — непрерываемый сон, T — остановлен и Z — зомби. Спящий процесс обычно просто ожидает работу.
Форма ps aux в стиле BSD выводит столбцы загрузки процессора и памяти, а также полные командные строки:
ps aux | head -n 10
При интерактивном использовании top непрерывно обновляет данные. Пакетный режим создаёт один стабильный снимок: параметр -b выбирает пакетный вывод, а -n 1 запрашивает одно обновление.
top -b -n 1 | head -n 12
В заголовке отображаются время работы, нагрузка, состояния задач, использование процессора и памяти. Таблица процессов ниже помогает найти активных потребителей ресурсов.
Теперь откройте интерактивное представление:
top
Наблюдайте за обновлением значений, найдите столбцы %CPU и %MEM, а затем нажмите q, чтобы вернуться в командную строку. Интерактивный top удобен, когда нужно наблюдать изменения во времени; пакетный режим лучше подходит, если вывод требуется сохранить или передать другой команде для обработки.
Сохраните целевой снимок процессов:
ps -eo pid,ppid,user,stat,comm --sort=pid > process-snapshot.txt
head -n 5 process-snapshot.txt
Запустите и найдите учебный процесс
На этом шаге вы запустите безопасный фоновый процесс, сохраните его PID и найдёте его с помощью ps и pgrep.
Символ & в конце команды просит оболочку выполнить команду в фоновом режиме и сразу вернуть приглашение. Запустите процесс sleep на пять минут с видимым именем labex-worker:
cd /home/labex/project/process-lab
bash -c 'exec -a labex-worker sleep 300' &
Специальное значение оболочки $! содержит PID последнего запущенного фонового процесса. Сохраните его до запуска другой фоновой команды:
worker_pid=$!
echo "$worker_pid" > worker.pid
Исследуйте именно этот процесс. Параметр -p выбирает PID, а -o задаёт поля:
ps -o pid,ppid,user,stat,etime,args -p "$worker_pid"
ETIME показывает прошедшее время работы, а ARGS содержит видимое имя процесса. Используйте pgrep -f для поиска по полной командной строке; параметр -a также выводит эту строку:
pgrep -af labex-worker
PID из вывода pgrep должен совпадать с содержимым worker.pid. Поиск по точному шаблону безопаснее, чем воздействие на каждый процесс с широко заданным именем.
Останавливайте процессы с помощью сигналов
На этом шаге вы запросите корректное завершение с помощью SIGTERM и примените SIGKILL только к процессу, специально настроенному игнорировать этот запрос.
Команда kill отправляет сигнал процессу по PID. Если сигнал явно не указан, отправляется SIGTERM, сигнал 15. SIGTERM запрашивает корректное завершение и даёт процессу возможность выполнить очистку.
Прочитайте PID рабочего процесса и отправьте SIGTERM:
cd /home/labex/project/process-lab
worker_pid=$(cat worker.pid)
kill "$worker_pid"
sleep 1
Следующая ожидаемая ошибка ps подтверждает, что процесс завершился:
ps -p "$worker_pid" || echo "labex-worker stopped after SIGTERM"
Теперь запустите управляемый процесс, который намеренно игнорирует SIGTERM:
bash -c 'trap "" TERM; exec -a labex-stubborn sleep 300' &
stubborn_pid=$!
echo "$stubborn_pid" > stubborn.pid
Подождите немного, чтобы новая оболочка успела установить обработчик сигнала:
sleep 1
Отправьте SIGTERM, немного подождите и исследуйте процесс:
kill -TERM "$stubborn_pid"
sleep 1
ps -o pid,stat,args -p "$stubborn_pid"
Процесс всё ещё должен присутствовать, поскольку этот учебный процесс игнорирует SIGTERM. SIGKILL, сигнал 9, нельзя перехватить или проигнорировать. Используйте его только после того, как корректный сигнал не дал результата:
kill -KILL "$stubborn_pid"
Завершите ожидающее фоновое задание. Ненулевой код завершения ожидаем, поэтому || true позволяет продолжить последовательность упражнений:
wait "$stubborn_pid" 2>/dev/null || true
ps -p "$stubborn_pid" || echo "labex-stubborn required SIGKILL"
SIGKILL не оставляет процессу возможности сохранить состояние или корректно освободить ресурсы приложения, поэтому это крайняя мера.
kill работает с известным PID. Если нужно выбрать процесс по имени или полной командной строке, pkill объединяет поиск и отправку сигнала. Запустите ещё один управляемый процесс с отличительной командной строкой:
bash -c 'exec -a labex-helper sleep 300' &
helper_pid=$!
echo "$helper_pid" > helper.pid
Перед воздействием убедитесь, что совпадение полной командной строки точное:
pgrep -af '^labex-helper 300$'
Отправьте SIGTERM точно найденному процессу с помощью pkill -f. Якоря ^ и $ не позволяют этому учебному шаблону совпадать с несвязанными командными строками:
pkill -TERM -f '^labex-helper 300$'
wait "$helper_pid" 2>/dev/null || true
ps -p "$helper_pid" || echo "labex-helper stopped by pkill"
Используйте точные шаблоны pkill и сначала проверяйте совпадения с помощью pgrep: широкие шаблоны могут остановить больше процессов, чем планировалось.
Управляйте заданиями переднего и фонового плана
На этом шаге вы приостановите команду переднего плана, возобновите её в фоне, вернёте на передний план и прервёте её.
Управление заданиями относится к текущей интерактивной оболочке. Запустите процесс sleep на переднем плане с узнаваемым именем:
cd /home/labex/project/process-lab
bash -c 'exec -a labex-job sleep 300'
Теперь терминал занят процессом переднего плана. Нажмите Ctrl+Z. Оболочка отправит сигнал остановки и вернёт приглашение.
Выведите задания, известные этой оболочке. Параметр -l добавляет идентификатор процесса:
jobs -l
Вы должны увидеть задание в состоянии Stopped. Возобновите задание с номером 1 в фоновом режиме:
bg %1
jobs -l
Теперь состояние должно быть Running, а приглашение останется доступным. Верните задание на передний план:
fg %1
Нажмите Ctrl+C, чтобы отправить сигнал прерывания заданию переднего плана. Приглашение должно вернуться. Убедитесь, что учебное задание не осталось:
pgrep -af labex-job || echo "No labex-job process remains"
После завершения интерактивной последовательности создайте маркер завершения:
touch job-control.done
Используйте управление заданиями для команд, связанных с текущим терминалом. Далее вы примените nohup для работы, которая не должна зависеть от сеанса терминала.
Прочитайте код завершения и запустите отсоединённую работу
На этом шаге вы интерпретируете код завершения команды и запустите короткую фоновую задачу, вывод которой сохранится независимо от отображения в терминале.
Каждая команда возвращает целочисленный код. Ноль означает успех, ненулевое значение — некоторую ошибку. Переменная оболочки $? содержит код завершения только что завершившейся команды.
Запустите успешную команду и сразу выведите её код:
cd /home/labex/project/process-lab
true
echo "true status: $?"
Результатом будет 0. Теперь запустите команду, которая не может найти указанный путь:
ls missing-path
Сохраните её код до того, как другая команда заменит значение $?:
missing_status=$?
echo "missing-path status: $missing_status"
Значение будет ненулевым. Сохраните обе ожидаемые интерпретации:
printf 'success=0\nfailure=%s\n' "$missing_status" > exit-status.txt
Команда nohup заставляет программу игнорировать сигнал разрыва связи с терминалом. Последний & запускает её в фоновом режиме. Перенаправление < /dev/null отключает ввод из терминала, а > nohup.log 2>&1 направляет оба потока вывода в журнал:
nohup bash -c 'for item in one two three; do echo "background: $item"; sleep 1; done' < /dev/null > nohup.log 2>&1 &
Сохраните PID фонового процесса и дождитесь завершения короткой задачи:
echo $! > nohup.pid
sleep 4
cat nohup.log
Вы должны увидеть три строки — от background: one до background: three. Для длительной работы сохранённые PID и журнал позволяют проверять ход выполнения.
Исследуйте последние сообщения ядра
На этом шаге вы исследуете буфер сообщений ядра и сохраните версию работающего ядра как стабильную справочную информацию.
Ядро записывает сообщения о запуске, оборудовании, драйверах и событиях во время работы в кольцевой буфер. Команда dmesg читает этот буфер. Обычно для этого требуются административные права:
cd /home/labex/project/process-lab
sudo dmesg | tail -n 10
Точные сообщения зависят от машины и времени. Обратите внимание на поле, похожее на метку времени, и на компонент или подсистему, создавшую каждое сообщение.
Параметр --level фильтрует сообщения по уровню серьёзности. Выведите последние предупреждения и ошибки:
sudo dmesg --level=err,warn | tail -n 10
Отсутствие вывода не означает, что команда завершилась с ошибкой: возможно, в текущем буфере нет сообщений этих уровней. Найдите в последних сообщениях распространённые термины, связанные с хранилищем и сетью:
sudo dmesg | grep -Ei 'disk|filesystem|network|eth' | tail -n 10
Результаты также зависят от текущей системы. Сохраните выпуск ядра, сообщаемый командой uname -r:
uname -r > kernel-version.txt
cat kernel-version.txt
Сообщения ядра — это свидетельства, а не готовые диагнозы. Прежде чем принимать решение, сопоставьте их с состоянием процессов, журналами служб и наблюдаемыми симптомами.
Итоги
Вы определили систему Linux, интерпретировали время работы и средние значения нагрузки, а также исследовали идентификаторы процессов, родительские процессы, владельцев, состояния и активность ресурсов с помощью снимков и интерактивных инструментов. Вы запускали и находили процессы по имени, точно выбирали их с помощью kill и pkill, использовали SIGTERM перед SIGKILL и практиковались в управлении заданиями переднего и фонового плана.
Кроме того, вы интерпретировали коды завершения, запускали отсоединённую работу с помощью nohup и явного журналирования, а также исследовали сообщения ядра с помощью dmesg. Эти привычки — сначала наблюдать, а затем действовать — лежат в основе безопасной диагностики процессов и подготовят вас к дальнейшей диагностике служб, журналов и сети в следующих разделах курса.
