pkill и pgrep — убиваем и ищем процессы по имени

Ситуация: на сервере завис процесс, и вы не знаете его PID. Вы делаете ps aux | grep nginx, находите PID, потом kill -9 PID. Три действия, которые можно сделать одним.

pgrep находит PID по имени процесса. pkill убивает процесс по имени. Вместо трёх действий - одно.

Базовое использование:

# Найти PID процесса по имени
pgrep nginx

# Убить все процессы с именем nginx
pkill nginx

# Убить только один процесс с точным совпадением имени
pkill -x nginx

Вариант 1 (Убить процесс по полному имени):

# Не убьёт nginx, если его имя "nginx: master process"
pkill -f "nginx: master"

Вариант 2 (Убить процессы от определённого пользователя):

pkill -u user python

Вариант 3 (Убить процесс, но сначала проверить, что будет убито):

pgrep -la python
# Вывод: 1234 python script.py
# 5678 python app.py

# Потом убить
pkill python

Вариант 4 (Принудительное убийство через -9):

pkill -9 python

Вариант 5 (Искать и убивать процессы, работающие больше N часов):

# Найти процессы, работающие больше 4 часов
pgrep -l -o -t 4

# Убить их
pkill -o -t 4

Вариант 6 (Игнорировать регистр):

pkill -i nginx

Установка: pkill и pgrep есть почти везде по умолчанию (в пакете procps).

Главный совет: сначала используйте pgrep -la name, чтобы убедиться, что найдены нужные процессы. Потом pkill. На одну команду больше, но безопаснее.

P.S. Самый полезный флаг - `-f` (полное имя команды). Он находит процесс по всей командной строке, а не только по имени бинарника.

dust - визуальный анализ диска, который работает быстрее ncdu

Ситуация: диск заполнился на 95%. ncdu показывает дерево папок, но сканирует долго. А если диск терабайтный, ждать приходится минуты.

dust (или dua) - это аналог ncdu, но написанный на Rust. Он сканирует диск быстрее, показывает те же деревья, но с более читаемым выводом и цветами.

Базовое использование:

dust

Вывод показывает список папок и файлов, отсортированный по размеру, с цветовой индикацией.

Вариант 1 (Сканировать конкретную папку):

dust /var/log

Вариант 2 (Ограничить глубину):

dust -d 3 /home

Показывает только три уровня вложенности.

Вариант 3 (Исключить определённые папки):

dust -x /home

-x - не выходить за пределы текущей файловой системы.

Вариант 4 (Вывод в процентах вместо байтов):

dust -p /var

Вариант 5 (Только папки, без файлов):

dust -f /home

Вариант 6 (Сравнить несколько папок):

dust /var/log /var/cache

Главный совет: используйте dust для быстрой первичной диагностики, когда нужно понять, какая папка жрёт место за секунды. Для глубокого анализа с удалением - ncdu всё ещё удобнее.

Пользуетесь dust или остались верны ncdu и du?

P.S. Есть ещё `dua` (Disk Usage Analyzer) - аналогичная утилита, тоже на Rust, с интерактивным режимом.

glances - мониторинг системы в реальном времени

Ситуация: на сервере что-то тормозит. Вы открываете htop - видите CPU и память. Открываете iotop - видите диск. Открываете iftop - видите сеть. Три терминала, три утилиты, глаза бегают.

glances - это единая панель, которая показывает всё сразу: CPU, память, диск, сеть, температуру, процессы, даже docker-контейнеры. И делает это в красивом интерфейсе.

Базовое использование:

glances

Вывод - экран с множеством разделов: загрузка каждого ядра CPU, использование памяти и swap, средняя нагрузка за 1, 5, 15 минут, чтение и запись на диск, входящий и исходящий сетевой трафик, топ процессов с сортировкой по любому столбцу и список Docker-контейнеров если они есть.

Вариант 1 (Включить веб-интерфейс):

glances -w

Открываете браузер, вводите http://localhost:61208 - и видите панель на удалённом сервере через браузер.

Вариант 2 (Удалённый мониторинг):

На сервере:

glances -s

На клиенте:

glances -c server_ip

Вариант 3 (Экспорт в JSON для автоматизации):

glances --export-json

Вариант 4 (Вывод только определённых данных - например, CPU и памяти):

glances --stdout cpu,mem

Вариант 5 (Мониторинг с порогами и уведомлениями):

glances --alerts

Если CPU выше 90%, память выше 80% или диск заполнен - появляется предупреждение красным цветом.

Навигация в glances:

- h — справка со всеми горячими клавишами
- q — выход
- 1 — переключить отображение CPU (все ядра или суммарно)
- 2 — переключить отображение дисков (все или только активные)
- b — переключить сортировку процессов (по CPU, памяти или I/O)
- f — показать встроенную справку по процессам

Сравнение с аналогами вкратце:

top показывает только CPU, память и процессы в базовом текстовом виде. htop делает то же самое, но цветным и интерактивным. iotop специализируется только на дисковом I/O. А glances объединяет всё это в одном экране - и CPU, и память, и диск, и сеть, и Docker, и температуру.

Главный совет: запомните флаг -w - веб-интерфейс. Один раз запустили на сервере и забыли. Мониторинг всегда доступен.

Пользуетесь glances или предпочитаете собирать информацию по частям из разных утилит?

P.S. `glances` можно запустить как демон (`glances -d`) и настроить отправку метрик в InfluxDB или другие системы мониторинга.

diff - покажи мне разницу

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

diff - это утилита, которая построчно сравнивает два файла и показывает, что добавилось, удалилось или изменилось. Без неё сравнивать файлы глазами - занятие для самых терпеливых.

Базовое использование:

diff file1.txt file2.txt

Вывод показывает:
- строки, которые есть только в первом файле (помечены <)
- строки, которые есть только во втором файле (помечены >)
- номера строк, где есть различия

Вариант 1 (Сравнить две папки рекурсивно):

diff -r dir1/ dir2/

Показывает, какие файлы добавились, удалились или изменились в папках.

Вариант 2 (Игнорировать пробелы и табуляции):

diff -w file1.txt file2.txt

Полезно, когда разница только в форматировании.

Вариант 3 (Показать только имена файлов, без содержимого):

diff -q -r dir1/ dir2/

Вариант 4 (Выдать результат в унифицированном формате):

diff -u file1.txt file2.txt

Унифицированный формат (тот, что показывает Git) - компактный и читаемый. Строки с - удалены, с + добавлены.

Вариант 5 (Сравнить, игнорируя регистр букв):

diff -i file1.txt file2.txt

Вариант 6 (Выдать результат для патча - можно применить позже):

diff -u file1.txt file2.txt > changes.diff

Созданный файл можно применить через patch:

patch file1.txt < changes.diff

Возможное применение #1 (сравнение конфигов до и после изменений):

diff -u /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

Сразу видно, какие строки добавили, какие убрали. Никаких "а что тут было раньше?".

Возможное применение #2 (проверка, изменился ли код после рефакторинга):

diff -r old_version/ new_version/ | grep "\.py"

Показывает только изменения в Python-файлах. Остальное игнорируем.

Главный совет: всегда используйте diff -u для унифицированного вывода. Он понятнее, компактнее и совместим с патчами.

Пользуетесь diff для сравнения файлов или открываете их в редакторе рядом и сравниваете глазами?

P.S. Если нужно сравнить содержимое папок с исключением определённых файлов (например, .git, __pycache__): `diff -r -x .git -x __pycache__ dir1/ dir2/`.

Heredoc - пишем многострочные скрипты без кавычек

Ситуация: вам нужно выполнить несколько команд на удалённом сервере через SSH. Или записать многострочный текст в файл. Или передать длинный SQL-запрос в базу. Оборачивать каждую строку в кавычки и экранировать спецсимволы - утомительно.

Heredoc (встроенный документ) - это конструкция в Bash, которая позволяет передавать многострочный текст как стандартный ввод для команды. И не нужно экранировать кавычки.

Базовый синтаксис:

command << EOF
строка 1
строка 2
строка 3
EOF

EOF - это метка-ограничитель. Можно использовать любую: END, STOP, BLOCK.

Вариант 1 (Записать многострочный текст в файл без echo для каждой строки):

cat > file.txt << EOF
первая строка
вторая строка
третья строка с "кавычками" и $переменными
EOF

Вместо 10 команд echo - один блок.

Вариант 2 (Выполнить несколько команд на удалённом сервере через SSH):

ssh user@server << EOF
cd /var/www
git pull
npm install
pm2 restart app
EOF

Все команды выполняются в одной SSH-сессии, как будто вы зашли на сервер и вводили их вручную.

Вариант 3 (Передать SQL-запрос в psql или mysql):

psql -U user -d dbname << EOF
SELECT * FROM users WHERE created_at > '2025-01-01';
UPDATE users SET status = 'active' WHERE status = 'pending';
EOF

Вариант 4 (Подавить интерполяцию переменных):

По умолчанию Heredoc подставляет значения переменных. Если нужно, чтобы переменные остались как есть, оберните ограничитель в кавычки:

cat > script.sh << 'EOF'
echo "Текущая директория: $PWD"
echo "Пользователь: $USER"
EOF

В файл запишется $PWD и $USER, а не их значения.

Вариант 5 (Подавить ведущие табуляции):

Если в Heredoc есть отступы, <<- удаляет их:

cat > file.txt <<- EOF
    строка с отступом
    тоже с отступом
EOF

---

Практическое применение #1 (создание скрипта на удалённом сервере):

ssh user@server "cat > /tmp/deploy.sh" << 'EOF'
#!/bin/bash
cd /var/www
git pull origin main
composer install --no-dev
php artisan migrate
EOF

ssh user@server "chmod +x /tmp/deploy.sh && /tmp/deploy.sh"

Практическое применение #2 (генерация конфига nginx из шаблона):

DOMAIN="example.com"
cat > /etc/nginx/sites-available/example.conf << EOF
server {
    listen 80;
    server_name $DOMAIN;
    root /var/www/$DOMAIN;
    index index.html;
}
EOF

Практическое применение #3 (проверка серии команд на удалённом сервере):

ssh staging-server << EOF
ps aux | grep nginx
df -h
uptime
EOF

Возможные ошибки:

- Пробел после `<<`: не должно быть пробела между << и EOF.
- Пробел перед EOF: строка с EOF не должна иметь пробелов в начале (если не используется <<-).
- Несовпадающий EOF: если открыли << EOF, закрывать нужно только EOF, не EOF с пробелами.

P.S. Есть ещё конструкция `<<< "строка"` - это "встроенная строка". Она передаёт одну строку как стандартный ввод. Например, `bc <<< "2+2"` вместо `echo "2+2" | bc`.