ДЕНЬ 06: Процесс-менеджер

LinuxBeginner
Практиковаться сейчас

Введение

Приветствуем вас, младший системный администратор! В «LabEx» выдалось напряженное утро понедельника: только что поступило критическое оповещение о том, что основной сервер приложений работает крайне медленно, что затрагивает всех пользователей. Старшие администраторы заняты на экстренном совещании, поэтому именно вам предстоит провести расследование и стабилизировать систему.

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

Важное примечание
Предстоящие задачи могут выходить за рамки курса Быстрый старт в Linux.
Если вы столкнетесь с трудностями во время испытания:
  1. Временно пропустите это испытание и продолжите работу с последующими практическими лабораториями в пути обучения Linux.
  2. Обсудите проблему с Labby или посмотрите решение.

Просмотр активных системных процессов

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

Задачи

  • Используйте одну команду, чтобы сгенерировать подробный список всех процессов, запущенных в системе.

Требования

  • Команда должна отображать процессы всех пользователей, а не только вашего.
  • Формат вывода должен быть ориентирован на пользователя, отображая такие детали, как владелец процесса, использование CPU/памяти и полную команду, которая его запустила.

Примеры

После выполнения команды вы должны увидеть вывод, похожий на этот:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 169848  9064 ?        Ss   08:30   0:02 /sbin/init
labex     1234  0.0  0.0   2324   564 pts/0    S+   08:35   0:00 bash /home/labex/project/resource_hog.sh
labex     1235  0.0  0.0   2324   564 ?        S    08:35   0:00 bash /home/labex/project/critical_service.sh
...

В выводе будет представлено множество процессов со столбцами для пользователя, идентификатора процесса (PID), использования процессора, использования памяти и команды запуска.

Подсказки

  • Самая распространенная команда для этой задачи — ps.
  • Подумайте, какие опции команды ps позволят показать процессы для всех пользователей (all), в удобном для человека формате (user-oriented) и включая процессы, не привязанные к терминалу (x).

Мониторинг использования ресурсов процессами

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

Задачи

  • Запустите интерактивную утилиту командной строки для мониторинга системных процессов и использования ими ресурсов в режиме реального времени.
  • Определите название скрипта, который потребляет больше всего ресурсов процессора (CPU).

Требования

  • Вы должны использовать инструмент, обеспечивающий непрерывно обновляемое представление системных процессов в реальном времени.
  • Инструмент должен позволять сортировать процессы по использованию CPU по умолчанию.
  • Как только вы определите главного потребителя, выйдите из инструмента, чтобы перейти к следующему шагу.

Примеры

При запуске инструмента мониторинга вы увидите интерактивный дисплей, который обновляется автоматически, отображая примерно следующее:

top - 09:15:30 up  1:45,  1 user,  load average: 1.50, 1.20, 0.85
Tasks: 105 total,   2 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.0 us,  5.0 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   2048.0 total,    850.4 free,    950.2 used,    247.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used,      0.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 labex     20   0   12884   1564   1320 R  95.0   0.1   2:15.30 bash /home/labex/project/resource_hog.sh
 1235 labex     20   0   12884   1564   1320 S   0.0   0.1   0:00.00 bash /home/labex/project/critical_service.sh
    1 root      20   0  169848   9064   6868 S   0.0   0.4   0:02.15 systemd
...

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

Подсказки

  • Эту популярную команду часто называют «Диспетчером задач» в мире Linux.
  • Выйти из этого интерактивного инструмента можно, нажав клавишу q.

Идентификация ключевых процессов

Вы нашли виновника: resource_hog.sh. Однако хороший системный администратор не завершает процессы без разбора. Вы также заметили работающий critical_service.sh. Прежде чем предпринимать какие-либо действия против «пожирателя ресурсов», вам следует идентифицировать и изучить все ключевые процессы, запущенные в системе.

Задачи

  • Найдите идентификатор процесса (PID) скрипта critical_service.sh.
  • Убедитесь, что критически важная служба работает правильно.

Требования

  • Вы должны использовать команду pgrep, чтобы найти PID процесса, выполняющего critical_service.sh.
  • Команда должна успешно найти запущенный процесс и отобразить его PID.

Примеры

После нахождения PID с помощью pgrep вы должны увидеть вывод типа:

1235

Это число (в данном примере 1235) является идентификатором процесса критически важной службы.

Вы можете проверить детали процесса с помощью:

ps -p 1235 -o pid,ppid,cmd

Что должно показать результат, похожий на:

PID PPID CMD
1235 1 /bin/bash /home/labex/project/critical_service.sh

Подсказки

  • pgrep может найти PID на основе имени процесса.
  • Используйте pgrep -f, чтобы выполнить поиск по всей командной строке запуска.

Завершение некорректного процесса

Теперь, когда вы идентифицировали ключевые процессы, пришло время разобраться с resource_hog.sh, который замедлял работу сервера. Вам нужно завершить этот процесс, чтобы восстановить нормальную работу.

Задачи

  • Завершите процесс resource_hog.sh.

Требования

  • Вы должны использовать команду, которая может завершить процесс по его имени, без необходимости предварительного поиска его PID.
  • Используйте команду pkill, чтобы остановить скрипт resource_hog.sh.

Примеры

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

labex 1234 95.0 0.0 2324 564 pts/0 R+ 09:15 5:00 bash /home/labex/project/resource_hog.sh

После успешного завершения выполнение той же команды проверки не должно показать соответствующих процессов (кроме самой команды grep):

labex 2345 0.0 0.0 2324 564 pts/0 S+ 09:20 0:00 grep resource_hog

Подсказки

  • Команда pkill отправляет сигнал завершения процессам на основе их имени.
  • После выполнения команды вы можете использовать ps aux | grep resource_hog, чтобы убедиться, что процесс больше не запущен.

Запуск и управление фоновыми процессами

Сервер снова стабилен! Отличная работа. Как раз в тот момент, когда вы собирались сделать перерыв, разработчик прислал вам сообщение. Им нужно, чтобы вы запустили на сервере длительный скрипт data_processor.sh. Вы не можете держать сессию терминала открытой часами только ради этого скрипта. Вам нужно запустить его в фоновом режиме, чтобы он продолжал работать даже после вашего выхода из системы.

Задачи

  • Запустите скрипт data_processor.sh так, чтобы он работал в фоновом режиме и был устойчив к разрыву соединения (т. е. не останавливался при закрытии терминала).

Требования

  • Вы должны находиться в директории ~/project.
  • Используйте команду nohup для запуска скрипта.
  • Используйте оператор &, чтобы отправить процесс в фоновый режим.
  • Перенаправьте весь вывод (как стандартный вывод, так и стандартную ошибку) скрипта в файл с именем processor.log.

Примеры

После успешного запуска скрипта в фоновом режиме вы должны увидеть вывод, похожий на:

[1] 3456
nohup: ignoring input and appending output to 'processor.log'

Запись [1] 3456 указывает на номер задания и идентификатор процесса. Вы можете убедиться, что скрипт работает, проверив файл лога:

cat processor.log

Это может показать что-то вроде:

Starting data processing at Mon Sep 11 10:30:00 UTC 2025

И вы можете подтвердить, что процесс все еще активен:

ps aux | grep data_processor

Это должно показать, что фоновый процесс запущен.

Подсказки

  • Команда nohup расшифровывается как «no hang up» (без обрыва).
  • Символ & в конце команды приказывает оболочке запустить её как фоновое задание.
  • Вы можете перенаправить стандартный вывод с помощью >, а стандартную ошибку — с помощью 2>&1.

Резюме

Поздравляем, администратор! Вы успешно справились с критической проблемой производительности сервера и продемонстрировали мастерство управления процессами в Linux. Сервер стабилен, приоритеты критически важных служб соблюдены, а длительные задачи успешно выполняются в фоновом режиме.

В этом испытании вы доказали свою способность:

  • Выводить и проверять все запущенные процессы с помощью ps.
  • Мониторить системные ресурсы в реальном времени с помощью top.
  • Идентифицировать важные процессы с помощью pgrep.
  • Корректно завершать проблемные процессы с помощью pkill.
  • Запускать и управлять фоновыми заданиями, которые продолжают работу после выхода из системы, используя nohup и &.

Это фундаментальные, высоко ценимые навыки, необходимые для любой роли в системном администрировании, DevOps или бэкенд-разработке. Вы превратили потенциальный кризис в возможность продемонстрировать свой профессионализм. Отличная работа!

✨ Проверить решение и практиковаться✨ Проверить решение и практиковаться✨ Проверить решение и практиковаться✨ Проверить решение и практиковаться✨ Проверить решение и практиковаться