Управление процессами в Linux: ps, kill, systemd и journalctl

Введение / Зачем это нужно

Управление процессами — одна из ключевых задач системного администратора и разработчика в Linux. Понимание того, как находить, анализировать, завершать и контролировать службы, позволяет быстро диагностировать проблемы с производительностью, высвобождать ресурсы и обеспечивать стабильную работу системы. Этот гайд покрывает как базовые команды (ps, kill), так и современный подход через systemd и анализ логов journalctl.

Требования / Подготовка

Доступ к терминалу с правами обычного пользователя. Для завершения чужих процессов и управления службами (systemctl, kill на чужие PID) потребуются права sudo.
Установленные базовые утилиты: procps (содержит ps, top), sysstat (содержит pidstat), htop (опционально, более удобная альтернатива top), systemd (стандарт для большинства современных дистрибутивов).
Знание PID (Process ID) — уникального идентификатора процесса. Его можно получить через ps или top.

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

Статический просмотр: `ps aux`

Команда ps aux выводит полный список всех процессов, запущенных всеми пользователями.

ps aux

Ключевые колонки:

USER — владелец процесса.
PID — идентификатор процесса (главное для управления).
%CPU, %MEM — использование ресурсов.
COMMAND — команда, запустившая процесс.

Фильтрация: Используйте grep для поиска по имени.

ps aux | grep nginx

Интерактивный мониторинг: `top` и `htop`

top — стандартная утилита. Нажмите q для выхода, k для завершения процесса (запросит PID).
htop — улучшенная версия с цветами, удобным интерфейсом и возможностью завершения процесса через F9. Установка: sudo apt install htop (Debian/Ubuntu) или sudo yum install htop (RHEL/CentOS).

htop

Поиск по PID или имени: `pgrep` и `pidof`

pgrep <имя_процесса> — вернет PID всех процессов, чье имя совпадает.
pidof <имя_процесса> — похоже, но менее гибко.

pgrep -l nginx  # Покажет PID и имя

Шаг 2: Завершение процессов (сигналы)

Процессы завершаются посылкой сигналов. Главные:

SIGTERM (15) — вежливая просьба завершиться. Процесс может обработать сигнал, завершить операции и выйти. Рекомендуемый первый вариант.
SIGKILL (9) — принудительное завершение. Ядро немедленно убивает процесс. Нельзя проигнорировать или обработать. Используйте, если SIGTERM не помог.
SIGHUP (1) — перезагрузка. Часто используется для служб, чтобы перечитать конфигурацию без полной остановки.

Команды для отправки сигналов

kill <PID> — отправляет SIGTERM (15) по умолчанию.
```
kill 1234
```
kill -s SIGKILL <PID> или kill -9 <PID> — отправляет SIGKILL.
```
kill -9 1234
```
pkill <имя_процесса> — завершает все процессы по имени (отправляет SIGTERM).
```
pkill nginx
```
killall <имя_процесса> — похоже на pkill, но точнее совпадает с именем команды.
```
killall -9 nginx  # Принудительно все nginx
```

Шаг 3: Управление службами systemd

В современных Linux (Ubuntu 16.04+, CentOS 7+, Fedora) основная работа с долгоживущими процессами (демонами) ведется через systemd.

Основные команды `systemctl`

systemctl status <служба> — подробный статус, последние логи.
```
systemctl status nginx
```
sudo systemctl start/stop/restart <служба> — управление состоянием.
```
sudo systemctl restart nginx
```
sudo systemctl enable/disable <служба> — включить/отключить автозапуск при загрузке.
```
sudo systemctl enable nginx
```
systemctl list-units --type=service --state=running — список всех запущенных служб.

Управление через `service` (устаревший, но совместимый)

На некоторых старых системах (или для совместимости) можно использовать:

sudo service nginx restart

Но systemctl — предпочтительный и более мощный инструмент.

Шаг 4: Просмотр логов служб с помощью journalctl

Логи systemd собираются в journal. Утилита journalctl — основной инструмент для их чтения.

Основые сценарии

Логи конкретной службы:

journalctl -u nginx.service --since "1 hour ago"

Отслеживание в реальном времени (аналог tail -f):
```
journalctl -u nginx.service -f
```
Логи с момента последней загрузки:
```
journalctl -b -u nginx.service
```
Фильтрация по приоритету (например, только ошибки):
```
journalctl -u nginx.service -p err
```
Показать логи определенного PID:
```
journalctl _PID=1234
```

Шаг 5: Поиск процессов по портам и файлам

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

По порту: `ss` (рекомендуется) или `netstat`

sudo ss -tulpn | grep :80
# -t: TCP, -u: UDP, -l: listening, -p: show process, -n: numeric

Вывод покажет pid и process name.

По файлу: `lsof` (List Open Files)

sudo lsof /var/log/nginx/access.log

Покажет все процессы, которые имеют открытым данный файл (чтение/запись).

Проверка результата

После завершения процесса: Убедитесь, что PID больше не отображается в ps aux или top.
```
ps aux | grep <имя_процесса>
```

После управления службой systemd: Проверьте статус.

systemctl is-active <служба>  # Должен вернуть 'active'
systemctl is-enabled <служба> # Должен вернуть 'enabled' (если включали)

После изменения конфигурации: Перезагрузите службу и проверьте логи на ошибки.
```
sudo systemctl restart <служба>
journalctl -u <служба>.service -n 50 --no-pager
```

Возможные проблемы

1. "Operation not permitted" при `kill` или `systemctl`

Причина: Вы пытаетесь завершить процесс, принадлежащий другому пользователю (обычно root), без прав sudo.
Решение: Используйте sudo kill <PID> или sudo systemctl ....

2. Процесс не завершается даже после `kill -9`

Причина: Процесс может находиться в состоянии Z (zombie) или D (uninterruptible sleep, обычно ожидание I/O).
Решение:
- Zombie: Это уже завершенный процесс, ожидающий родителя, который прочитает его статус. Нельзя убить, нужно перезапустить родительский процесс.
- Состояние D: Часто вызвано проблемами с NFS или "зависшим" драйвером оборудования. Единственный выход — перезагрузка системы или устранение причины зависания I/O.

3. Служба systemd не запускается после `start`

Причина: Ошибка в конфигурационном файле службы (.service) или в самом приложении.

Решение: Смотрите логи сразу после попытки запуска.

sudo systemctl start <служба>
journalctl -u <служба>.service -n 50 --no-pager  # Покажет последние 50 строк

Ищите строки с Failed или Error.

4. `journalctl` показывает "No journal files were found"

Причина: Journaling отключен или логи очищены. Иногда это происходит в минималистичных контейнерах (Docker) или если в /etc/systemd/journald.conf стоит Storage=none.
Решение: Проверьте конфиг sudo cat /etc/systemd/journald.conf. Для включения постоянного хранения раскомментируйте Storage=auto (или persistent) и перезапустите sudo systemctl restart systemd-journald. Если нужно сохранить логи, настройте ротацию.

Часто задаваемые вопросы

Как найти PID процесса по имени?

В чем разница между SIGTERM (15) и SIGKILL (9)?

Что делать, если процесс не завершается даже после kill -9?

Как посмотреть, какая служба использует порт 80?

Полезное

Поиск активных процессов (ps, top, htop)

Завершение процесса по PID или имени (kill, pkill)

Управление службами systemd (systemctl)

Анализ логов служб (journalctl)

Поиск процессов по порту или файлу (ss, lsof)

Управление процессами в Linux: ps, kill, systemd и journalctl

Часто задаваемые вопросы

Полезное

Похожее