Найти в Дзене
Ivan-Yurievich

5 команд Linux, которые я использую каждый день уже 10 лет

Знаете, есть такие инструменты, которые используешь настолько часто, что они становятся частью мышечной памяти. Открываешь терминал — и пальцы сами набирают нужное, даже не думая. Вот про такие команды я и хочу рассказать. Это не список «топ-100 команд Linux для начинающих» из учебника. Это именно то, что я реально использую каждый день. Некоторые из них простые, некоторые — с нюансами, про которые не пишут в базовых туториалах. Поехали. Я администрирую серверы уже больше десяти лет. За это время через мои руки прошли десятки машин — от маленьких VPS за копейки до серьёзных продакшн-серверов. Ubuntu, Debian, CentOS, Arch — работал с разным. И вот что интересно: несмотря на всё разнообразие задач, базовый набор команд остаётся примерно одинаковым. Я не буду рассказывать про ls и cd — это вы и без меня знаете. Расскажу про то, что реально экономит время и нервы. Казалось бы, что тут рассказывать? grep знают все. Но большинство используют его на 10% от возможностей. Базовое использование
Оглавление

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

Это не список «топ-100 команд Linux для начинающих» из учебника. Это именно то, что я реально использую каждый день. Некоторые из них простые, некоторые — с нюансами, про которые не пишут в базовых туториалах. Поехали.

Немного контекста — кто я и зачем мне это

Я администрирую серверы уже больше десяти лет. За это время через мои руки прошли десятки машин — от маленьких VPS за копейки до серьёзных продакшн-серверов. Ubuntu, Debian, CentOS, Arch — работал с разным. И вот что интересно: несмотря на всё разнообразие задач, базовый набор команд остаётся примерно одинаковым.

Я не буду рассказывать про ls и cd — это вы и без меня знаете. Расскажу про то, что реально экономит время и нервы.

1. grep — поиск, который умеет всё

Казалось бы, что тут рассказывать? grep знают все. Но большинство используют его на 10% от возможностей.

Базовое использование — найти строку в файле:

bash

grep "error" /var/log/nginx/error.log

Но вот где начинается настоящая магия:

Рекурсивный поиск по всей директории:

bash

grep -r "database_host" /etc/

Ищет строку во всех файлах внутри /etc/. Незаменимо, когда не помнишь, в каком именно конфиге прописал нужную переменную.

Поиск с контекстом — несколько строк вокруг совпадения:

bash

grep -C 5 "fatal error" /var/log/app/app.log

Флаг -C 5 покажет 5 строк до и после совпадения. Очень помогает при разборе логов — видишь не просто ошибку, а что происходило вокруг неё.

Инвертированный поиск — всё, кроме:

bash

grep -v "DEBUG" /var/log/app/app.log

Отфильтровать дебаг-сообщения из лога и оставить только важное — это использую постоянно.

Поиск без учёта регистра:

bash

grep -i "nginx" /var/log/syslog

Показать только имена файлов с совпадением:

bash

grep -rl "secret_key" /var/www/

Флаг -l — просто список файлов, без содержимого. Удобно, когда нужно найти, где вообще упоминается что-то важное.

Мой любимый трюк — grep по выводу другой команды:

bash

ps aux | grep nginx

или

bash

systemctl list-units | grep failed

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

Отдельно скажу про grep -E или egrep — это расширенные регулярные выражения. Если освоить хотя бы базовые регулярки, grep превращается в суперсилу. Например:

bash

grep -E "ERROR|CRITICAL|FATAL" /var/log/app/app.log

Ищет сразу несколько паттернов. Одна команда — и ты видишь все критические события в логе.

2. tmux — потому что закрытое окно не должно убивать процесс

Это, пожалуй, команда, которая изменила мою работу сильнее всего. Если вы ещё не используете tmux — бросайте всё и идите ставить.

Проблема без tmux выглядит так: подключаешься по SSH к серверу, запускаешь долгую операцию — деплой, бэкап, компиляцию — и в этот момент рвётся соединение. Всё. Процесс убит. Начинай сначала.

С tmux такого не происходит. Сессия живёт на сервере независимо от твоего SSH-соединения.

Создать новую сессию:

bash

tmux new -s myproject
```

**Отсоединиться от сессии (сессия остаётся жить):**
```
Ctrl+B, затем D

Список активных сессий:

bash

tmux ls

Подключиться обратно к сессии:

bash

tmux attach -t myproject
```

Но tmux — это не только про «не убивать процессы при разрыве соединения». Это полноценный мультиплексор терминала. Можно разделить экран на несколько панелей и работать параллельно:
```
Ctrl+B, затем % — разделить вертикально
Ctrl+B, затем " — разделить горизонтально
Ctrl+B, затем стрелки — переключаться между панелями

У меня типичная рабочая раскладка: слева редактор, справа — терминал для запуска команд, снизу — логи в реальном времени через tail -f. Всё в одном окне, ничего не теряется.

Ещё один сценарий, который использую постоянно: запустил деплой на сервере, отсоединился, занялся другим делом, через полчаса подключился и проверил результат. Без tmux это было бы или «сиди и жди», или «надейся на лучшее».

3. rsync — копирование файлов, которое умеет думать

cp — это хорошо. Но rsync — это другой уровень.

Главное отличие rsync от обычного копирования: он синхронизирует, а не просто копирует. Если файл уже есть и не изменился — он его не тронет. Если изменилась только часть большого файла — передаст только изменения. Это экономит и время, и трафик.

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

bash

rsync -avz /source/ /destination/

Флаги:

  • -a — архивный режим (сохраняет права, метаданные, рекурсивно)
  • -v — verbose, показывает что происходит
  • -z — сжатие при передаче

Синхронизация с удалённым сервером:

bash

rsync -avz /var/www/mysite/ user@server:/var/www/mysite/

Это я использую для бэкапов и деплоя статики. Первый раз — передаёт всё. Последующие разы — только изменения. При деплое большого проекта разница между «передать всё» и «передать только изменения» может быть огромной.

Мой любимый флаг — --dry-run:

bash

rsync -avz --dry-run /source/ /destination/

Показывает, что будет сделано, не делая ничего на самом деле. Всегда использую перед серьёзными операциями — посмотреть, что изменится, и убедиться что всё правильно.

Удалить файлы в назначении, которых нет в источнике:

bash

rsync -avz --delete /source/ /destination/

Флаг --delete — осторожно с ним. Но для синхронизации бэкапов незаменим.

Исключить папки:

bash

rsync -avz --exclude='node_modules' --exclude='.git' /var/www/project/ user@server:/var/www/project/

Не копировать node_modules при деплое — это базовая гигиена. Без этого флага можно передавать гигабайты мусора.

4. htop — потому что top — это каменный век

top есть на любом Linux. Но как только я впервые попробовал htop — к top уже не вернулся.

htop — это интерактивный монитор процессов. Цветной, удобный, с мышкой (да, прямо в терминале).

Установка, если нет:

bash

apt install htop # Debian/Ubuntu
yum install htop # CentOS/RHEL
```

Что умеет `htop`, чего не умеет `top`:

**Сортировка одним нажатием** — кликаешь на заголовок колонки (CPU%, MEM%) и список сортируется. В `top` для этого нужно помнить hotkeys.

**Дерево процессов:**
```
F5
```
Нажимаешь F5 — и видишь иерархию процессов. Кто кого запустил, какие дочерние процессы. Очень помогает, когда нужно понять, почему сервер тормозит — видишь всю картину.

**Убить процесс без запоминания PID:**
Находишь процесс в списке, нажимаешь F9 — выбираешь сигнал (SIGTERM, SIGKILL и т.д.). Никаких `kill -9 $(ps aux | grep...)` — просто навёл, нажал.

**Поиск процесса:**
```
F3

Начинаешь вводить имя — список фильтруется в реальном времени.

Цветовая индикация нагрузки — сразу видно, какое ядро загружено, сколько памяти занято и чем. Не нужно расшифровывать колонки цифр.

Я запускаю htop на любом новом сервере, который начинаю администрировать. Первые 5 минут — просто смотрю на живой снимок системы. Сразу видно аномалии, если они есть.

5. journalctl — логи, которые умеют фильтровать

Если вы работаете с systemd-системами (а это большинство современных дистрибутивов), journalctl — это ваш главный инструмент для работы с логами.

Раньше каждый сервис писал свои логи куда попало — /var/log/nginx/, /var/log/mysql/, /var/log/syslog... Надо было знать, где у каждого сервиса лежат его логи. С journalctl всё в одном месте.

Посмотреть логи конкретного сервиса:

bash

journalctl -u nginx

Логи в реальном времени (аналог tail -f):

bash

journalctl -u nginx -f

Флаг -f — follow. Смотришь на живой поток логов. Очень удобно при отладке — открываешь в одном окне tmux journalctl -f, в другом делаешь действие и сразу видишь что происходит.

Логи за последний час:

bash

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

Логи за конкретный период:

bash

journalctl -u postgresql --since "2024-01-15 10:00:00" --until "2024-01-15 12:00:00"

Это я использую при разборе инцидентов. Что-то упало в 11:30 — смотришь логи за этот период и видишь картину.

Только ошибки:

bash

journalctl -u myapp -p err

Флаг -p фильтрует по приоритету: err, warning, info, debug. Не надо grep'ать — журнал сам отдаёт нужное.

Посмотреть логи с момента последней загрузки системы:

bash

journalctl -b

Сколько места занимают логи:

bash

journalctl --disk-usage

И если нужно почистить:

bash

journalctl --vacuum-time=30d

Оставляет логи только за последние 30 дней. Иногда это нужно — журнал может разрастись до нескольких гигабайт на активном сервере.

Бонус: комбинации, которые я использую чаще всего

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

Найти, кто занимает порт:

bash

ss -tulpn | grep :80

Посмотреть размер директорий:

bash

du -sh /var/www/* | sort -hr

Показывает размер каждой папки в /var/www/, отсортированный по убыванию. Сразу видно, кто «жирный».

Следить за логами нескольких сервисов одновременно:

bash

journalctl -f -u nginx -u php-fpm -u postgresql

Найти большие файлы на диске:

bash

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr

Ищет файлы больше 100 МБ по всей системе. Незаменимо, когда диск внезапно заканчивается и непонятно почему.

Быстрый бэкап конфига перед правкой:

bash

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d_%H%M%S)

Всегда делаю это перед тем, как лезть в конфиг. Имя файла содержит дату и время — можно откатиться в любой момент.

Что изучить дальше

Если хочешь прокачать работу в терминале — вот направления, которые дадут максимальный результат:

Bash-скрипты. Когда понимаешь, что делаешь одно и то же руками больше двух раз — пора автоматизировать. Даже простые скрипты на 10-20 строк экономят кучу времени.

Регулярные выражения. Страшно звучит, но базовый уровень осваивается за день. И после этого grep, sed, awk становятся в разы мощнее.

awk и sed. Обработка текста и замена в файлах. Вместе с grep образуют мощнейший инструментарий для работы с логами и конфигами.

ansible. Когда серверов становится больше одного — ручное управление превращается в ад. Ansible позволяет описывать конфигурацию серверов как код и применять её автоматически.

Итог

Пять команд — grep, tmux, rsync, htop, journalctl. Каждая из них простая, но каждая решает реальные проблемы, с которыми ты сталкиваешься каждый день.

Не нужно знать все 500 команд Linux. Нужно хорошо знать те, которые реально используешь. Остальное подтянется по мере необходимости — гугл и man-страницы никуда не денутся.

Если ты только начинаешь — начни с grep и htop. Они дают результат сразу. Потом поставь tmux и привыкни работать через него. А rsync и journalctl придут естественно, когда задачи усложнятся.

Пиши в комментарии — какие команды у тебя в мышечной памяти? Интересно, у всех ли набор похожий или у каждого своя любимая «магия».