Как управлять зависшими приложениями и мониторить систему в Linux

О нет — что‑то явно идёт не так с компьютером! В Windows вы обычно открываете Диспетчер задач сочетанием клавиш Ctrl + Alt + Delete, находите проблемный процесс и закрываете его. В Linux те же горячие клавиши могут вести себя иначе. Но не переживайте: в «пингвиновом» мире существует множество способов посмотреть состояние системы и корректно завершить некорректно работающие программы. Здесь вы найдёте и графические варианты, похожие на Windows Task Manager, и набор команд для терминала, дающих больше контроля.

Быстрый обзор подходов

• Графические приложения удобны новичкам и дают визуальную информацию: GNOME System Monitor, KDE System Monitor (KSysGuard), XFCE Task Manager.
• Командная строка даёт гибкость и возможна в окружениях без GUI: ps, top, htop, kill, killall, xkill, vmstat, free, lscpu.
• Если приложение не закрывается обычным SIGTERM, используйте SIGKILL (signal 9), но сначала попытайтесь корректно завершить работу — это снижает риск потери данных.

Графические приложения — похожие на «Диспетчер задач»

Эти программы наглядны и просты: список процессов, нагрузка CPU/RAM, сетевой трафик и использование диска. Конкретный вид зависит от рабочего окружения (GNOME, KDE, XFCE), но функциональность схожа.

1. GNOME System Monitor

Приложение по умолчанию в среде GNOME фокусируется на процессах, ресурсах и файловых системах. Первая вкладка показывает запущенные процессы, пользователя, PID и нагрузку. При выборе процесса появляется кнопка «End Process» (Завершить процесс) — она пытается корректно завершить процесс, но не всегда это срабатывает; в сложных случаях понадобится терминал.

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

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

2. KDE System Monitor (KSysGuard)

KSysGuard предлагает меньший набор вкладок: «Process Table» и «System Load». Первая показывает процессы и использование памяти; процесс можно закрыть правым кликом -> «End Process». Вторая вкладка — графики загрузки CPU, памяти и сети.

KDE традиционно гибок в настройке: можно добавлять новые вкладки с информацией о разделах, логах и других метриках.

3. XFCE Task Manager

Лёгкий менеджер задач XFCE не использует вкладки: сверху — графики CPU и памяти, снизу — список процессов. Здесь доступны несколько способов «убить» процесс: Stop, Terminate, Kill — каждая кнопка отправляет разные сигналы, от мягкого завершения до принудительного.

Совет: используйте XFCE на системах с ограниченными ресурсами или в старых ноутбуках.

Настройка сочетания клавиш Ctrl + Alt + Delete для вызова монитора системы

По умолчанию Ctrl + Alt + Delete в большинстве окружений открывает меню выхода/перезагрузки, а не диспетчер задач. Изменить поведение просто.

Пример для GNOME:

1. Откройте Settings > Keyboard.
2. В разделе Shortcuts найдите Custom Shortcuts и нажмите «+».
3. Введите имя ярлыка и команду запуска (для GNOME System Monitor это gnome-system-monitor).
4. Установите сочетание клавиш, зажав нужные клавиши — например Ctrl + Alt + Delete.
5. Подтвердите замену предыдущей функции, если система спросит.

После этого сочетание клавиш будет запускать выбранное приложение. Аналогичные шаги работают и в других окружениях: ищите раздел управления клавишами в настройках вашего десктопа.

Примечание: точные меню и термины зависят от версии окружения и языка локали.

Командная строка — гибкость и контроль

Переход в терминал нужен, когда GUI недоступен, приложение не реагирует на графические попытки закрытия, или вы управляете удалённым сервером. Ниже — обзор основных команд, их назначение и практические примеры.

ps — узнать, какие процессы запущены

Коротко: ps = process status. Часто используют с ключами “aux” или “-ef”:

ps aux | grep firefox
ps -ef | grep myapp

ps показывает PID (process ID), пользователя, использование CPU и памяти, командную строку процесса — эти данные нужны для последующего управления.

kill и killall — корректное и принудительное завершение

Команда kill отправляет сигнал процессу по PID. По умолчанию сигнал SIGTERM (15) — это вежливый запрос на завершение.

# Вежливое завершение
kill 2470

# Принудительное завершение (SIGKILL)
kill -9 2470

SIGKILL (9) насильственно завершает процесс; он не может быть перехвачен, но использование SIGKILL повышает риск потери данных, поскольку процесс не успевает выполнить очистку.

killall завершает процессы по имени:

killall firefox

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

xkill — «кликни и закрой» для X11

Если вы не знаете имя процесса, запустите xkill в терминале. Курсор превратится в “крестик” — кликните по окну, и оно закроется.

Ограничение: xkill работает в окружениях на базе X11; в Wayland он может быть недоступен или работать иначе.

top и htop — живой монитор процессов

top показывает процессы в реальном времени, сортируя по загрузке CPU. htop — более удобная, цветная замена с возможностью навигации стрелками и отправки сигналов прямо из интерфейса.

Команды:

top
htop   # если установлено

В htop можно выбрать процесс и нажать F9 для отправки сигнала (включая SIGTERM и SIGKILL).

vmstat — снимок состояния системы

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

Пример:

vmstat 1 5   # снять статистику с интервалом 1 сек, 5 раз

free — сколько памяти доступно

free показывает свободную и занятую физическую память и swap. В современных системах Linux память активно используется для кеша и буферов — не паникуйте если «used» велико, смотрите поле “available”.

free -h   # читабельные единицы (KB/MB/GB)

lscpu — информация о CPU и архитектуре

lscpu даёт удобное представление о количестве ядер, потоков, архитектуре и других характеристиках CPU — полезно, чтобы понять, как распределяется нагрузка.

lscpu

Пошаговый SOP: что делать при зависшем приложении

1. Определите вид проблемы: одно окно или вся ОС? (GUI реагирует/нет)
2. Попробуйте корректно завершить приложение через GUI (End/Terminate).
3. Если не сработало, используйте xkill (если X11) или закройте окно через диспетчер задач.
4. Если GUI недоступен или процесс не закрывается — в терминале: ps/pgrep -> kill PID (SIGTERM).
5. Если SIGTERM не помогает через 5–10 секунд — kill -9 PID (SIGKILL).
6. Если проблема системная (swap/IO перегружены) — перезагрузите систему безопасно: sudo reboot.
7. После восстановления проанализируйте логи (/var/log/syslog, journalctl) и повторите шаги воспроизведения.

Краткий пример команд:

# Найти процесс по имени
pgrep -a firefox
# Вежливо завершить
kill 12345
# Если не помогает, принудительно
kill -9 12345

Важно: для управления процессами, принадлежащими другому пользователю, потребуются права root (sudo).

План реагирования на инцидент: runbook

• Приоритет 1 (производство недоступно): если зависание затрагивает сервисы, влияющие на клиентов — уведомьте команду, переключите трафик (если есть), выполните перезапуск сервисов.
• Приоритет 2 (локальный рабочий стол): попробуйте мягкое завершение, затем принудительное. Если это повторяется — создайте issue с деталями (логи, шаги воспроизведения).
• После инцидента: соберите логи, сделайте скриншоты, обновите SOP и уведомьте заинтересованные стороны.

Критерии приёмки:

• Приложение корректно завершено и не висит в списке процессов.
• Система возвращена в работоспособное состояние без деградации сервисов.
• Логи сохранены и проблема задокументирована.

Чек‑листы по ролям

Администратор сервера:

• Есть доступ по SSH.
• Проверены метрики CPU/memory/I/O.
• Приняты меры по разгрузке (перезапуск сервисов, масштабирование).
• Логи сохранены.

Пользователь рабочего стола:

• Попробовал закрыть через GUI.
• Если не помогло, использовал xkill или System Monitor.
• Сохранил несохранённые данные, если это возможно.
• Сообщил в баг‑трекер с шагами воспроизведения.

Разработчик:

• Собрал трассировки и стек вызовов.
• Проверил, не вызвано ли зависание дедлоком или утечкой памяти.
• Запустил приложение под отладчиком или с дополнительной логгировкой.

Когда стандартные методы не работают — альтернативы и ограничения

• Если процесс «завис» в ядре (ожидание системного вызова), SIGKILL может не помочь. В таких случаях единственный выход — перезагрузка.
• В Wayland некоторые графические трюки (xkill) не работают; используйте специализированные утилиты окружения или TTY.
• Если приложение регулярно зависает, рассмотрите запуск в изолированной среде (контейнер, отдельный пользователь) или обновление/замену приложения.

Ментальные модели и эвристики

• Начните с наименее инвазивных действий (GUI -> SIGTERM -> SIGKILL -> reboot).
• «Мягкое завершение»—сохраняет состояние; «жёсткое» — устраняет проблему быстрее, но с риском потери данных.
• Диагностика — это уменьшение пространства возможных причин: процесс/память/диск/сеть/ядро.

Небольшая методология для повторяемой диагностики

1. Сбор метрик: top/htop, free, vmstat.
2. Локализация: какой процесс грузит систему? ps/pgrep.
3. Вмешательство: graceful -> forceful -> system reboot.
4. Пост‑анализ: journalctl, /var/log/*, трассировки.
5. Превенция: патчи, ограничения ресурсов (cgroups), мониторинг.

Примеры тестов и критерии приёмки

Тесты:

• Запуск нагрузочного теста, имитирующего пиковую нагрузку, и проверка, что система остаётся отзывчивой в течение 10 минут.
• Имитирование зависания приложения и проверка, что SOP успешно завершает процесс и восстанавливает работоспособность.

Критерии приёмки:

• Доступность основных сервисов > 95% в течение теста.
• Процесс корректно убирается из списка процессов после выполнения runbook.

Глоссарий в одну строку

• PID — идентификатор процесса; уникален для каждого запущенного процесса.
• SIGTERM — мягкий сигнал на завершение процесса (15).
• SIGKILL — принудительное завершение процесса (9), без возможности перехвата.
• xkill — инструмент X11 для закрытия окна кликом.

Риски и рекомендации по смягчению

• Риск потери данных при SIGKILL: перед применением убедитесь, что нет открытых несохранённых документов.
• Риск «зависания в ядре»: если процесс ожидает системный вызов, попробуйте выяснить причину через strace, но перезагрузка может быть единственным выходом.
• Риск недоступности сервиса после перезагрузки: перед reboot — проверьте зависимости и уведомите пользователей.

Decision tree (Mermaid)

flowchart TD
  A[Приложение не отвечает] --> B{GUI реагирует?}
  B -- Да --> C[Попробовать закрыть через GUI]
  C --> D{Закрылось?}
  D -- Да --> E[Завершено]
  D -- Нет --> F[Запустить xkill 'если X11' или System Monitor]
  F --> G{Закрылось?}
  G -- Да --> E
  G -- Нет --> H[Открыть терминал]
  B -- Нет --> H
  H --> I[Найти PID: ps/pgrep]
  I --> J[Отправить SIGTERM: kill PID]
  J --> K{Процесс завершился?}
  K -- Да --> E
  K -- Нет --> L[Отправить SIGKILL: kill -9 PID]
  L --> M{Завершился?}
  M -- Да --> E
  M -- Нет --> N[Перезагрузка/дальнейшая диагностика 'strace, kernel logs']

Что делать после восстановления

• Соберите логи и снимки состояния (journalctl, dmesg).
• Документируйте временную метку, шаги и вывод команд.
• Если проблема повторяется, откройте баг‑репорт с полной информацией.
• Рассмотрите внедрение мониторинга (Prometheus, Grafana) и ограничений на ресурсы (systemd slices, cgroups) для предотвращения повторений.

Заключение

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

Важно: перед применением принудительных методов сохраняйте данные, когда это возможно.

Мы будем рады вашему опыту: какие инструменты вы предпочитаете для диагностики и завершения процессов? Какой у вас стандартный набор команд при инциденте? Поделитесь своими практиками.