Блог компании 3v-Hosting
11 мин.
В Linux есть некий перечень команд, которые наиболее часто используются практически всеми администраторами. К примеру команды ls, cd, grep, top, df, ps знают, наверное, даже те, кто открывает терминал всего пару раз в месяц. Чуть реже используются такие команды как awk, sed, find, systemctl, но и они входят в стандартный рабочий набор администратора.
Но есть и второй эшелон инструментов, которые решают вполне практические задачи, так-же как и первые часто уже установлены в системе*, однако вспоминают о них обычно после двадцати минут возни с grep, пайпами или чтением /proc.
Мы выбрали десять Linux-команд именно из этой категории, чтобы напомнить о них и показать, как они могут пригодиться при администрировании сервера, поиске неисправностей или обычной работе в консоли. Давайте вспоминать, а с некоторыми знакомиться заново.
*Небольшая оговорка. Набор предустановленных утилит зависит от дистрибутива и типа установки. В минимальных образах Ubuntu/Debian, AlmaLinux/Rocky и особенно в контейнерах некоторые команды могут отсутствовать. В таком случае нужный пакет можно установить из стандартного репозитория.
Также стоит упомянуть, что в данной статье мы знакомимся со всеми командами обзорно, так сказать, а полный перечень их параметров всегда доступен для самостоятельного ознакомления через
man <команда>или документацию утилиты в интернете.
Как в большинстве случаев просматривают информацию о каком либо файле? Ну конечно командой ls, например так:
ls -l backup.tar.gz
Для большинства рабочих задач этого вполне хватает. Но вот иногда хочется в одном месте получить информацию об inode, увидеть права на файл в числовом виде или разобраться, когда файл действительно последний раз изменялся. В таком случае пригодится команда stat:
stat backup.tar.gz
Её вывод будет примерно таким:
File: backup.tar.gz Size: 104857600 Inode: 1849231 Access: (0644/-rw-r--r--) Access: 2026-09-30 08:41:12 Modify: 2026-09-28 03:15:44 Change: 2026-09-29 12:06:18
Особенно интересны здесь три временные метки, Access, Modify и Change, которые указывают, соответственно, на дату и время последнего доступа к этому файлу, на дату и время последнего изменения содержимого файла и на дату и время изменению метаданных файла.
Между вторым и третьим параметром разница в том, что, например, после команды chmod содержимое файла останется прежним, но вот ctime изменится, что и отобразится в параметре Change. Такая мелочь иногда помогает понять, что происходило с подозрительным файлом.
Также этой команде можно указать, в каком формате выдавать результат, что может быть удобным вариантом для использования в скриптах и пайплайнах:
stat -c '%n %s %a %U:%G' *
Выполненная в таком виде команда выводит имя файла, размер в байтах, права и владельца без необходимости парсить результат простого ls.
Бесспорно, старый добрый netstat до сих пор встречается в инструкциях десятилетней давности. Но в современных Linux-системах для многих его задач всё чаще используется команда ss - от Socket Statistics.
Например следующая команда покажет TCP- и UDP-сокеты, слушающие порты и связанные с ними процессы:
ss -tulpn
Поэтому вопрос о том, кто занял порт 8080, решается коротко:
ss -ltnp | grep ':8080'
Можно получить примерно такой ответ:
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=2841,fd=47))
Теперь понятно, куда копать дальше, ведь мы видим, что порт держит процесс java с PID 2841.
Приведём ещё пару полезных вариантов использования:
ss -tn state established
покажет установленные TCP-соединения, а:
ss -s
даст короткую сетевую статистику.
При проблемах с сетью ss часто позволяет за несколько секунд увидеть то, что иначе пришлось бы искать по нескольким другим командам заметно дольше.
Название этой утилиты расшифровывается как List Open Files. Звучит скучновато, не правда ли? Но это только до тех пор, пока мы не вспомним, насколько широко Linux трактует понятие файла. Поэтому область применения команды lsof гораздо шире просмотра открытых на данный момент документов.
Так, если вам нужно выяснить, кто использует конкретный порт, то набирайте команду:
lsof -i :443
Кто держит конкретный файл:
lsof /var/log/nginx/access.log
Какие файлы открыл определенный процесс:
lsof -p 1234
Если перейти к понятному, наглядному примеру, то представьте, что есть сервер и он пишет логи, которые забивают дисковое пространство. Вы удалили самый распухший лог, но место на диске не очистилось. В таком случае выполняем команду:
lsof +L1
И в её выдаче можно обнаружить что-нибудь такое:
COMMAND PID USER FD SIZE/OFF NAME java 2841 app 12w 18G /var/log/app.log (deleted)
Это означает, что как такового файла в каталоге уже нет, но вот процесс продолжает держать открытый файловый дескриптор и пока он его не закроет, занятое место может не освободиться.
Вот ради таких случаев о команде lsof точно стоит помнить.
Если вам необходимо просто пару минут понаблюдать, меняется ли состояние сервера прямо сейчас, то вам вовсе не обязательно ставить какие нибудь системы мониторинга, вроде Prometheus, Grafana и городить большой дашборд.
Для этого есть простая команда watch, которая "в прямом эфире" показывает изменение тех или иных параметров. Например для мониторинга занятой оперативной памяти выполняем:
watch -n 2 free -h
Каждые две секунды free -h будет запускаться заново, а экран будет автоматически обновляться.
Так же можно наблюдать за заполнением диска:
watch -n 2 'df -h /'
Или смотреть состояние того или иного сервиса:
watch -n 1 'systemctl is-active nginx'
Особенно удобно использовать параметр -d, который подсвечивает изменения между обновлениями:
watch -d -n 1 'ss -s'
Получается простенький маленький монитор практически из любой консольной команды. Например мы запустили копирование большого файла, бекап или какой-нибудь другой долгий процесс - и смотрим за заполнением дискового пространства.
Бывает, запускаешь команду и заранее не знаешь, сколько по времени она будет выполняться, ведь может пропасть связь с сетевым ресурсом, скрипт может зависнуть или уйти в цикл, ну и т.п. Поэтому лучше будет сразу ограничить время выполнения:
timeout 30s ./script.sh
И если спустя 30 секунд процесс все еще работает, то timeout остановит его принудительно.
Еще парочка примеров о задачах которых вы сами догадаетесь:
timeout 10s ssh server.example.com uptime
Или:
timeout 5s curl https://example.com
Также, после срабатывания лимита можно проверить код возврата и выполнив:
timeout 3s sleep 10 echo $?
мы получим:
124
Так скрипт может понять, что команда завершилась именно из-за превышения заданного времени.
Использование команды timeout особенно удачно работает в случаях автоматизации, когда, например, ваша Cron-задача или служебный скрипт не должны бесконечно висеть только потому, что один внешний ресурс перестал отвечать.
Данный инструмент по своему назначению немного пересекается с lsof, но выдаёт ответ в более коротком формате.
Например команда :
fuser /var/log/app.log
может вернуть:
/var/log/app.log: 2841
В результате мы видим PID процесса, который использует файл.
С портами это работает похожим образом:
fuser 8080/tcp
А для более полного вывода есть параметр -v:
fuser -v 8080/tcp
Результат будет приблизительно таким:
USER PID ACCESS COMMAND 8080/tcp: app 2841 F.... java
Теперь становится видно и пользователя, и процесс.
У fuser также есть параметр -k, позволяющий завершать найденные процессы. Но тут лучше не торопиться, особенно под root, чтобы не уронить систему.
Резюмируем: если нужен подробный отчет, то обычно удобнее использовать lsof, но если хочется за пару секунд связать файл или порт с PID, то fuser отлично подходит.
При работе с процессами достаточно часто появляется необходимость просмотреть все запущенные в системе процессы. Для этого, чаще всего, используется стандартная командаps aux, которая показывает все процессы в виде простого длинного списка. И восстановить родственные связи между ними становится сложно без использования дополнительных утилит. А вот команда pstree сразу строит дерево процессов в наглядном виде.
Попробуем:
pstree -p
И вместо скучно таблицы получится дерево из которого сразу видно, кто кого запустил.:
systemd(1) ├─sshd(821) │ └─sshd(1532) │ └─bash(1540) └─nginx(902) ├─nginx(903) └─nginx(904)
Можно исследовать и какой-то конкретный процесс:
pstree -p 1532
Или посмотреть его родителей:
pstree -sp 1540
Это особенно удобно при работе с демонами, shell-скриптами, worker-процессами и приложениями, которые порождают целое семейство дочерних процессов.
Да, сам системный журнал journalctl секретом давно не является. Но некоторые его возможности вспоминают заметно реже. Так например один из самых полезных вариантов его использования является возможность просмотра журнала последней перезагрузки системы с помощью параметров:
journalctl -b -1
Например ночью ваш сервер завис или неожиданно перезагрузился и после перезапуска все снова работает как и раньше. В текущий журнал уже пишутся события после рестарта, хотя интересует нас именно то, что происходило перед ним.
Можно и фильтровать, чтобы увидеть только предупреждения или ошибки:
journalctl -b -1 -p warning
А сообщения ядра предыдущей загрузки можно посмотреть так:
journalctl -k -b -1
Там могут обнаружиться следы OOM, ошибки диска, проблемы драйвера или другие события, происходившие непосредственно перед аварией.
При отыскании проблем с системой, будет очень полезным знать еще одну команду:
journalctl --list-boots
Она покажет сохраненные загрузки системы в формате:
IDX BOOT ID FIRST ENTRY LAST ENTRY -2 d65a9269caee412bb6a8d887c8fc0678 Thu 2026-07-30 18:38:31 EEST Sun 2026-08-02 17:21:18 EEST -1 415be0912ce04afdb422362c1c514a99 Sun 2026-08-02 17:21:37 EEST Fri 2026-09-11 09:40:58 EEST 0 347bca10383740be9f5e5d6306dbc02f Sun 2026-09-13 06:36:18 EEST Wed 2026-09-30 15:22:51 EEST
При работе с консолью Linux часто появляется необходимость взять результат выполнения одной команды и передать его другой команде. Например, найти десятки файлов, а затем удалить их, проверить или выполнить над каждым какое-то действие. Обычный конвейер через здесь | подходит не всегда, так как одна программа может выводить список каких либо данных, а следующая ожидать их в виде аргументов командной строки.
Именно для таких случаев и существует xargs. Он берет полученные данные, превращая их в аргументы, и запускает с ними указанную команду.
Представим, что в файле hosts.txt записаны адреса нескольких серверов:
server1.example.com server2.example.com server3.example.com server4.example.com
Нам нужно проверить каждый из них с помощью команды ping. Для этого в левой части мы читаем список этих серверов и передаём их в правую часть на команду пинг:
cat hosts.txt | xargs -n 1 ping -c 1
Параметр -n 1 говорит xargs передавать команде по одному адресу. В результате последовательно будут выполнены проверки каждого сервера из списка.
Если серверов много, то задачу можно распараллелить:
cat hosts.txt | xargs -P 4 -n 1 ping -c 1
Параметр -P 4 разрешает одновременно запустить до четырех процессов ping. И такой прием удобен не только для проверки серверов, так как через xargs можно пакетно обрабатывать файлы, запускать скрипты для списка объектов или передавать большой набор результатов другой программе.
Правда при работе с файлами есть небольшой нюанс. Так, если в имени файла встречается пробел, обычная передача списка может неправильно воспринять одно имя как несколько отдельных аргументов.
Например, безопасный вариант поиска ошибок сразу во всех .log-файлах будет выглядет так:
find . -name '*.log' -print0 | xargs -0 grep 'ERROR'
Тут find находит все файлы с расширением .log, а xargs передает их команде grep, которая ищет внутри строку ERROR. Параметры -print0 и -0 нужны здесь для корректной работы с именами, содержащими пробелы. Например, файл old server.log останется одним файлом, а не разделится на old и server.log.
Снова вернёмся к решению проблем с серверами и в данном случае разберём вариант длительной загрузки сервера после рестарта или включения. Допустим ваш сервер загружается пять минут и вы понятия не имеете, на что именно тратится столько времени.
В таком случае нужно для начала посмотреть общее время загрузки командой:
systemd-analyze
После этого нам необходимо получить список unit-файлов и продолжительность их запуска::
systemd-analyze blame
Результат:
21.304s NetworkManager-wait-online.service 8.411s mariadb.service 4.281s docker.service 2.930s cloud-init.service
Казалось-бы, что виновник уже найден. Но большое время рядом с каким-то сервисом еще не доказывает, что именно он задержал всю загрузку, так как многие unit-файлы запускаются параллельно.
Поэтому есть еще одна, волшебная, команда:
systemd-analyze critical-chain
Она показывает критическую цепочку загрузки, а именно зависимости, которые действительно влияли на достижение нужного состояния системы.
Есть у systemd-analyze и более наглядный режим - команда, которая умеет строить график загрузки системы:
systemd-analyze plot > boot.svg
В результате выполнения этой команды появится файл boot.svg, который можно открыть обычным браузером. На графике будет видно, когда запускались отдельные сервисы и сколько времени занял каждый из них. Поэтому если сервер долго загружается, то такой график позволяет буквально глазами найти длинные задержки и посмотреть, какие сервисы работали в этот момент.
Детальнее с проблемой длительной загрузки Linux-серверов мы разбирались в отдельной статье.
Итак, мы с вами вспомнили 10 команд, которые способны значительно облегчить жизнь каждому Linux администратору. Безусловно, учить десятки параметров каждой из этих команд наизусть - бессмысленно. Достаточно хотя-бы помнить, что подходящий инструмент вообще существует, чтобы в случае надобности копнуть немного глубже. А чтобы легче было запомнить, вот простая шпаргалка:
| Задача | Команда |
|---|---|
| Посмотреть подробные метаданные файла | stat |
| Проверить сокеты и сетевые соединения | ss |
| Найти процесс, открывший файл или порт | lsof |
| Повторять команду через интервал | watch |
| Ограничить время выполнения | timeout |
| Быстро найти PID по файлу или порту | fuser |
| Увидеть иерархию процессов | pstree |
| Изучить предыдущую загрузку | journalctl -b -1 |
| Передать набор аргументов другой команде | xargs |
| Исследовать скорость загрузки системы | systemd-analyze |
Нет. Большинство из них есть в стандартных репозиториях популярных дистрибутивов, но в минимальной установке или контейнере некоторые утилиты могут отсутствовать. В таком случае достаточно установить соответствующий пакет через пакетный менеджер.
В справочной системе man или официальной документации конкретной утилиты в интернете. В статье приведены только наиболее показательные сценарии использования, но у большинства этих команд возможностей намного больше.
fuser отличается от lsof?fuser удобен для быстрого поиска процесса, который использует определенный файл или порт. lsof выводит более подробную информацию об открытых файлах, процессах и сетевых соединениях. Выбор зависит от того, насколько подробный ответ нужен.
Обычный пользователь не имеет доступа ко всей информации о процессах других пользователей и открытых ими ресурсах. Поэтому диагностические утилиты при запуске с правами root иногда показывают более полную картину.
Да. Это обычные Linux-утилиты, поэтому они одинаково применимы на VPS, физических серверах и локальных Linux-машинах. Ограничения могут появиться лишь в контейнерах или сильно урезанных системах.
Для сетевых проблем пригодятся ss, lsof и fuser, после неожиданной перезагрузки - journalctl, а причины медленной загрузки помогает искать systemd-analyze. stat, watch, timeout, pstree и xargs чаще решают более узкие задачи.
Docker exec - это мощный инструмент для выполнения команд внутри работающего контейнера Docker без его остановки или перезапуска. В этой статье мы рассмотрим ег...
Одним из самых удобных и понятных способов работы с файлами и их передачей между серверами или между вашим локальным компьютером и удаленным сервером - является...
Достаточно часто, при пользовании смартфоном мы можем сталкиваться с проблемами, которые по сути своей связанны с работой службы DNS и DNS кэшем на вашем устрой...
Чек-лист ежемесячного обслуживания Linux-сервера с проверкой обновлений, дисков, логов, безопасности, фоновых задач и резервных копий. Практические команды и по...
Оптимизация загрузки Linux-сервера помогает найти задержки в systemd, сети, ядре и fstab, проверить критическую цепочку и сократить общее время запуска системы.
Что делать, если закончилось место в /var на Linux-сервере. Пошаговая диагностика и безопасная очистка логов, Docker, journald и APT в Debian и Ubuntu.
