Блог компанії 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 Неділя, 2 серпня 2026 р., 17:21:37 EEST П’ятниця, 11 вересня 2026 р., 09:40:58 EEST 0 347bca10383740be9f5e5d6306dbc02f Неділя, 13 вересня 2026 р., 06:36:18 EEST Середа, 30 вересня 2026 р., 15:22:51 EEST
Під час роботи з консоллю Linux часто виникає необхідність взяти результат виконання однієї команди та передати його іншій команді. Наприклад, знайти десятки файлів, а потім видалити їх, перевірити або виконати над кожним якусь дію. Звичайний конвеєр через | підходить не завжди, оскільки одна програма може виводити список певних даних, а наступна - очікувати їх у вигляді аргументів командного рядка.
Саме для таких випадків і існує xargs. Він бере отримані дані, перетворюючи їх на аргументи, і запускає з ними вказану команду.
Уявімо, що у файлі hosts.txtзаписані адреси кількох серверів:
server1.example.com server2.example.com server3.example.com server4.example.com
Нам потрібно перевірити кожен із них за допомогою команди ping. Для цього у лівій частині ми зчитуємо список цих серверів і передаємо їх у праву частину для команди 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,304 с NetworkManager-wait-online.service 8,411 с mariadb.service 4,281 с docker.service 2,930 с 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 без його зупинки або перезапуску. У цій статті ми розглянемо йо...
Одним з найзручніших і зрозумілих способів роботи з файлами та їх передачею між серверами або між вашим локальним комп'ютером та віддаленим сервером є FTP-серве...
Досить часто, при користуванні смартфоном ми можемо стикатися з проблемами, які по суті пов'язані з роботою служби DNS і DNS кешем на вашому пристрої. У цій ста...
Перелік завдань щомісячного обслуговування Linux-сервера, що включає перевірку оновлень, дисків, журналів, безпеки, фонових завдань та резервних копій. Практичн...
Оптимізація завантаження Linux-сервера допомагає виявити затримки в systemd, мережі, ядрі та fstab, перевірити критичний ланцюжок і скоротити загальний час запу...
Що робити, якщо закінчився простір у /var на Linux-сервері. Покрокова діагностика та безпечне очищення логів, Docker, journald та APT у Debian та Ubuntu.
