Команды, которые мы запускаем перед устранением неполадок в любой системе Linux

• Прежде чем приступать к устранению неполадок в любой системе Linux, выполните небольшой набор команд только для чтения, чтобы зафиксировать текущее состояние системы до того, как любое вмешательство нарушит ход событий.
• Основные проверки: идентификация системы (hostnamectl, uname -a), нагрузка на ресурсы (top, free -h, df -h, df -i), недавние ошибки (journalctl -p 3 -xb), сбойные службы (systemctl --failed), состояние сети (ip a, ss -tulnp).
• Сначала наблюдайте, ничего не меняйте и дайте системе самой сообщить вам, что не так.

Введение

Когда ко нам обращаются с просьбой устранить неполадки в системе, мы не сразу хватаемся за решение проблемы. Мы быстро анализируем систему. Обычно через минуту-другую мы уже знаем, в чем проблема. Не точное решение, но направление поиска.

Прежде чем начать

Использует ли ваша система systemd?

Большинство современных дистрибутивов Linux, таких как Ubuntu 16.04+, Debian 8+, RHEL/CentOS 7+, Fedora 15+, используют systemd в качестве системы инициализации.

Чтобы проверить, выполните следующую команду:

ps -p 1 -o comm=

Проверьте, использует ли ваша система Linux systemd

Если в выводе указано systemd, значит, вы работаете в системе на базе systemd и все команды из этой статьи применимы. Если указано init или sysvinit, используйте резервные команды, указанные в каждом разделе.

Вам нужен root-доступ?

Некоторые команды возвращают неполный вывод для обычных пользователей. Если вы сомневаетесь, добавляйте к командам префикс с sudo. Члены групп systemd-journal, adm или wheel могут читать системные журналы без полного root-доступа.

Краткое руководство: полный набор команд

Для администраторов, которым нужны команды без пояснений. Если вы новичок в администрировании Linux, пропустите этот блок и прочтите полное руководство ниже — контекст важнее скорости.

# 1. Идентификатор системы
hostnamectl; uname -a; cat /etc/os-release; whoami; uptime; date

# 2. Нехватка ресурсов
top -b -n1 | head -20
free -h && df -h && df -i

# 3. Журналы — ошибки текущей загрузки
journalctl -p 3 -xb

# 4. Сбои в работе сервисов
systemctl --failed
journalctl -p 3 -b -1 # также проверьте предыдущую загрузку

# 5. Структура диска и подключения
lsblk && mount | column -t

# 6. Сеть
ip a; ip route
ss -tulnp
ping -c 3 8.8.8.8

# 7. Последние действия
last -n 5; who
ps aux --sort=-%cpu | head

# 8. Ведение журнала сеансов — сначала запустите этот скрипт в рабочих системах
script troubleshoot.log
# ... выполните диагностические команды ...
# По завершении введите: exit
# Затем сразу же установите права доступа:
chmod 600 troubleshoot.log

Шаг 1. Определите систему идентификации

Первое, что мне нужно, — это понять, с чем я имею дело.

hostnamectl
uname -a
cat /etc/os-release
whoami
uptime
date

Это занимает тридцать секунд.

Команда hostnamectl позволяет получить информацию об операционной системе, ядре и имени хоста.

uname -a подтверждает архитектуру процессора.

А команда cat /etc/os-release заполняет поле с названием и версией дистрибутива.

Все эти три пункта помогут вам понять, в какую среду вы попадаете, прежде чем делать какие-либо выводы.

uptime показывает, как долго работает система и какова ее текущая средняя нагрузка. date подтверждает правильность системных часов.

На что обратить внимание:

• Очень недавняя отметка времени перезагрузки в uptime сама по себе является тревожным сигналом — что-то вызвало перезагрузку.
• Среднее значение загрузки выше количества ядер процессора (показано в nproc) указывает на то, что система перегружена.
• Отклонение date от реального времени на несколько минут или часов означает наличие дрейфа времени. Даже несколько минут дрейфа незаметно приводят к сбоям в проверке TLS-сертификатов, аутентификации Kerberos, планировании заданий cron и синхронизации временных меток в системах.

Пример вывода, касающегося uptime:

up 3 minutes, 1 user, load average: 0.02, 0.08, 0.03

Три минуты работы сервера, который должен работать непрерывно, — что-то вызвало недавний перезапуск.

Шаг 2. Проверьте нагрузку на системные ресурсы

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

top -b -n1 | head -20
free -h
df -h
df -i

Что означает каждая команда:

top -b -n1 | head -20 запускает top в пакетном режиме (неинтерактивном), делает один снимок и отображает первые 20 строк.

Посмотрите на следующее:

• %Cpu(s): если sy (система) или wa (ожидание ввода-вывода) работают с высокой нагрузкой, значит, ядро перегружено.
• load average: три числа, показывающие среднее количество процессов, ожидающих выполнения, за последние 1, 5 и 15 минут. Если значение постоянно превышает количество ядер вашего процессора, это проблема.
• Список процессов: все, что потребляет необычно много %CPU или %MEM.

free -h отображает использование оперативной памяти и файла подкачки в удобочитаемых единицах измерения (МБ/ГБ).

              total        used        free      shared  buff/cache   available
Mem:           15Gi        12Gi       512Mi       256Mi       2.5Gi       2.8Gi
Swap:           2Gi         2Gi          0B

Swap на 100 % при почти полном отсутствии доступной оперативной памяти означает, что система исчерпала ресурсы памяти и выгружает все данные на диск — это распространенная причина крайне низкой производительности.

df -h показывает объем дискового пространства для каждой подключенной файловой системы.

Filesystem      Size  Used Avail Use%  Mounted on
/dev/sda1        20G   20G     0  100% /

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

df -i показывает использование индексного дескриптора. Индексный дескриптор — это структура данных, которую файловая система использует для отслеживания метаданных каждого файла. В файловых системах ext4 количество индексных дескрипторов фиксируется при форматировании. Когда все индексные дескрипторы используются, система не может создавать новые файлы, даже если на диске остаются свободные гигабайты. Это приводит к той же ошибке «на устройстве не осталось места» при заполнении диска, но без очевидной причины в df -h.

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      1310720 1310720      0  100% /

IUse% на уровне 100 % при наличии свободного места на диске = исчерпание индексных дескрипторов. Примечание: это касается только ext4. XFS и btrfs динамически распределяют индексные дескрипторы и не имеют такого ограничения.

Если top недоступен, используйте эту команду:

ps aux --sort=-%cpu | head

Шаг 3. Сначала просмотрите логи

Как только мы убеждаемся, что система не испытывает явной нехватки ресурсов, мы сразу же обращаемся к логам. Именно там можно найти большинство ответов.

systemd — это система инициализации и менеджер служб, используемый в большинстве современных дистрибутивов Linux. Она ведет структурированный журнал под названием journal, который можно просматривать с помощью journalctl.

journalctl -p 3 -xb

Срывая флаги:

• -p 3 — фильтрация по уровню приоритета 3 (ошибка) и выше. В Linux используются уровни приоритета системного журнала, где чем меньше число, тем выше уровень: 0=emerg, 1=alert, 2=crit, 3=err. Этот флаг показывает только четыре самых серьезных уровня.
• -x— добавление пояснительного контекста к записям журнала, если это возможно.
• -b — отображение только записей за текущую загрузку. Без этого параметра отображается вся история.

Вот как выглядит тревожная запись:

Apr 10 14:32:01 hostname kernel: Out of memory: Killed process 1234
Apr 10 14:32:01 hostname systemd[1]: nginx.service: Main process exited
Apr 10 14:32:01 hostname systemd[1]: nginx.service: Failed with result

Это означает, что ядру не хватило памяти, оно завершило процесс, и в результате nginx перестал работать. Вот и вся первопричина в трех строках.

Прочтите несколько строк до и после каждой ошибки. Повторяющиеся паттерны важнее отдельных сообщений. Одна ошибка в 3 часа ночи — это не то же самое, что одна и та же ошибка, повторяющаяся каждые 30 секунд.

Сообщения ядра (аппаратные ошибки, ошибки диска, проблемы с драйверами):

# Примечание: временные метки -T могут быть неточными в системах, которые были приостановлены или возобновлены после последней загрузки.
dmesg -T | tail -50

Флаг -T преобразует необработанные временные метки, привязанные к загрузке системы, в удобочитаемые даты и время. Однако это преобразование может быть неточным на любом компьютере, который был переведен в режим ожидания с момента последней полной загрузки, поскольку источник времени в ядре не обновляется во время перехода в режим ожидания и выхода из него. Если вы диагностируете ноутбук или любую другую систему, которая переходит в режим ожидания, используйте journalctl для получения достоверных временных меток.

В системах без systemd читайте файлы журналов напрямую:

cat /var/log/syslog # Debian / Ubuntu
cat /var/log/messages # RHEL / CentOS / Fedora

Что делать с найденными данными: Если в журнале указано, что произошел сбой в работе определенной службы, ошибка диска или нарушение прав доступа, это и есть отправная точка. Перейдите к шагу 4. Если в журнале вообще ничего не указано, расширьте фильтр с помощью journalctl -p 5 -xb (включая предупреждения) или проверьте журналы приложений в разделе /var/log/.

Шаг 4. Определение служб, в работе которых произошел сбой

systemd отслеживает состояние каждой службы. Если служба выходит из строя и не восстанавливается, она переходит в состояние failed и остается в нем до тех пор, пока не будет перезапущена вручную. Эта команда выводит список всех служб, находящихся в таком состоянии.

systemctl --failed

Работоспособный системный вывод:

0 loaded units listed.

Неработоспособный системный вывод:

  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service        loaded failed failed A high performance web server
● postgresql.service   loaded failed failed PostgreSQL RDBMS

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

2 loaded units listed.

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

Важная оговорка: состояние сбоя сбрасывается при успешном перезапуске службы или при запуске systemctl reset-failed. В унаследованной системе список может быть уже пуст, даже если сбои происходили ранее. Всегда проверяйте журнал предыдущей загрузки.

journalctl -p 3 -b -1

(-b -1 означает «загрузку перед текущей».)

Как только вы обнаружите сбой в работе сервиса, сразу же просмотрите его логи:

journalctl -u nginx.service -b

Замените nginx.service на название вышедшего из строя модуля. Так вы увидите все, что служба зарегистрировала при текущей загрузке, — это гораздо полезнее, чем обзор всей системы.

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

systemctl list-units --type=service --state=running

В системах без systemd:

service --status-all

Затем просмотрите соответствующие файлы в разделе /var/log/.

Шаг 5. Проверьте структуру диска и подключения

Даже если на шаге 2 с дисковым пространством все было в порядке, мы все равно проверяем физическую структуру хранилища.

lsblk
mount | column -t

lsblk перечисляет все блочные устройства (физические диски, разделы и логические тома) в виде древовидной структуры.

Исправный сервер может выглядеть так:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 49G 0 part /
└─sda2 8:2 0 1G 0 part [SWAP]

Ищите: отсутствующие диски (исчезнувшие из списка), разделы без точки подключения или неожиданные устройства.

mount | column -t показывает все подключенные в данный момент файловые системы с их параметрами. Ищите файловые системы, подключенные с помощью ro (только для чтения), в столбце параметров:

/dev/sda1 / ext4 ro,relatime 0 0

Если файловая система смонтирована только для чтения, это обычно означает, что ядро обнаружило ошибки и перемонтировало ее, чтобы предотвратить дальнейшее повреждение. Система будет работать нормально до тех пор, пока что-нибудь не попытается записать данные, — тогда все сломается без видимой причины. Проверьте dmesg -T | tail -50 наличие ошибки на диске. Возможно, вам придется добавить к этой команде префикс sudo.

Шаг 6. Проверьте подключение к сети (если применимо)

Мы не начинаем с проверки подключения к сети, если проблема не в этом. В противном случае мы делаем следующее:

ip a
ip route
ss -tulnp
ping -c 3 8.8.8.8

ip a здесь перечислены все сетевые интерфейсы и их IP-адреса. Обратите внимание на интерфейсы, которые отключены DOWN, хотя должны быть активны, или на интерфейсы, у которых отсутствует IP-адрес.

ip route отображает таблицу маршрутизации. Важная строка — маршрут по умолчанию:

default via 192.168.1.1 dev eth0

Отсутствие маршрута по умолчанию означает, что система не может получить доступ ни к чему за пределами своей локальной сети.

ss -tulnp выводит список всех прослушиваемых сетевых сокетов с указанием процесса, которому они принадлежат. Это ответ на распространенный вопрос: действительно ли служба прослушивает тот порт, который должен прослушивать?

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:80          users:(("nginx",pid=1234))
tcp    LISTEN  0.0.0.0:22          users:(("sshd",pid=5678))

Если предполагается, что nginx работает на 80-м порту, но его нет в списке, значит, он не запущен — независимо от того, что может утверждать systemctl status .

ping -c 3 8.8.8.8 отправляет три пакета на DNS-сервер Google. Важно: неудачный пинг не всегда означает, что сеть не работает. Протокол ICMP (который используется в пинге) может быть заблокирован брандмауэром, в то время как TCP-трафик проходит нормально. Используйте пинг для проверки базового исходящего подключения, а не для диагностики сбоев в работе конкретных приложений.

Если тесты на подключение проходят успешно, но соединение не устанавливается, проверьте правила брандмауэра и DNS, а не только пинг.

iptables -L -n # Традиционный iptables (большинство систем)
nft list ruleset # nftables (современные системы — проверьте, какая команда применима)

Чтобы проверить, использует ли ваша система iptables или nftables, выполните следующие действия:

iptables -V # показывает версию, если она доступна
nft -v # показывает версию, если она доступна

Для решения проблем с DNS:

resolvectl status # Только если запущен systemd-resolved
cat /etc/resolv.conf # Всегда работает — показывает настроенные DNS-серверы

Шаг 7. Поиск причин, связанных с человеческим фактором или процессами

Не все проблемы связаны с оборудованием или конфигурацией. Иногда что-то меняется или какой-то процесс дает сбой.

last -n 5
who
ps aux --sort=-%cpu | head

last -n 5 отображает пять последних входов в систему. Если незадолго до возникновения проблемы в систему вошел неизвестный пользователь, это может быть зацепкой, за которой стоит понаблюдать.

who показывает, кто в данный момент вошел в систему. Несколько активных сеансов на сервере, который должен работать без участия пользователя, могут указывать на несанкционированный доступ или сбой в работе скрипта обслуживания.

ps aux --sort=-%cpu | head отображает десять процессов, потребляющих больше всего ресурсов процессора. Законный процесс должен быть идентифицирован по названию. Неизвестный процесс в верхней части списка требует изучения.

Шаг 8. Зафиксируйте сеанс перед началом работы

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

script troubleshoot.log

Это запускает запись сеанса. Все, что вы вводите, и каждая строка вывода записываются в troubleshoot.log. Работайте в обычном режиме. Когда закончите, завершите сеанс, набрав:

exit

Сразу после этого заблокируйте файл:

chmod 600 troubleshoot.log

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

Если вести полный журнал сеансов нецелесообразно, вместо этого сделайте снимок текущего состояния.

( set -x; uname -a; uptime; df -h; df -i; free -h; systemctl --failed ) &> snapshot.txt

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

$ cat snapshot.txt 
+ uname -a
Linux debian13desktop 6.12.74+deb13+1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux
+ uptime
 19:02:23 up  8:02,  2 users,  load average: 0.00, 0.00, 0.00
+ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           795M  1.3M  794M   1% /run
/dev/sda1        47G  8.9G   36G  21% /
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs           3.9G   16K  3.9G   1% /tmp
tmpfs           795M  104K  795M   1% /run/user/1001
+ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
udev           1008030    407 1007623    1% /dev
tmpfs          1017316    743 1016573    1% /run
/dev/sda1      3106880 264616 2842264    9% /
tmpfs          1017316      4 1017312    1% /dev/shm
tmpfs          1017316      4 1017312    1% /run/lock
tmpfs             1024      1    1023    1% /run/credentials/systemd-journald.service
tmpfs          1048576     35 1048541    1% /tmp
tmpfs           203463    148  203315    1% /run/user/1001
+ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.4Gi       5.7Gi       6.1Mi       881Mi       6.3Gi
Swap:          2.6Gi          0B       2.6Gi
+ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Что показывает первый проход

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

Три типичных случая

Случай 1: «Сервер работает медленно».

Проверьте df -h. Корневая файловая система загружена на 100 %.

Проверьте journalctl -p 3 -xb. Журнал переполнен сообщениями об ошибках записи и попытках перезапуска службы.

Вывод: диск заполнен. Все остальное — замедление работы, перезапуски, ошибки приложений — это последствия. Сначала освободите место на диске. «Замедление» пройдет само собой.

Случай 2: «Сайт не работает».

Проверьте, отображается ли systemctl --failed. nginx.service в списке.

Проверьте journalctl -u nginx.service -b. В журнале отображается:

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Что-то еще уже прослушивает порт 80. Проверьте, ss -tulnp | grep :80 чтобы найти это. Разрешите конфликт портов перед перезапуском nginx.

Случай 3: «Никто не может связаться с сервером»

ping сбой с другой машины. Но сам сервер, похоже, в порядке.

Проверьте iptables -L -n. Слишком широкое правило блокирует весь входящий трафик, кроме SSH. Недавнее изменение в системе безопасности ввело это правило без его тестирования.

Вывод: неправильная конфигурация брандмауэра. Сервер работает нормально — трафик блокируется до того, как поступает на какой-либо сервис.

Чего не делают опытные администраторы

• Не перезапускайте службы, не разобравшись в проблеме. После сбоя службы остаются логи, дампы памяти и файлы блокировки, по которым можно понять, что произошло. Перезапуск стирает все эти данные.
• Не перезагружайте систему «просто чтобы проверить, поможет ли это». При перезагрузке очищается журнал текущей загрузки, поэтому journalctl -b становится бесполезным для анализа произошедшего. Всегда читайте логи перед перезагрузкой.
• Не вносите изменения в конфигурацию, не прочитав логи. Возможно, вы решаете не ту проблему и только усугубляете ситуацию.

Каждое из этих действий уничтожает улики. Как только их не станет, вы будете строить догадки вместо того, чтобы ставить диагноз.

Единственный важный процесс

Со временем все это превратилось в простую схему:

1. Наблюдайте: изучите систему, прежде чем приступать к работе
2. Сузьте область поиска: сначала исключите распространенные причины
3. Действуйте: внесите одно изменение, проверьте результат, повторите

Если первый шаг сделан правильно, все остальное пойдет как по маслу. В противном случае все будет работать медленнее и менее надежно.

Ссылки:

• journalctl
• systemctl
• dmesg
• iostat
• resolvectl
• Gentoo Wiki: на устройстве не осталось свободного места, хотя его предостаточно

Редактор: AndreyEx