Базовые команды Linux: ищем причину сбоя на сервере

После выкладки сайт начал отвечать ошибкой 500. Не перезапускайте всё подряд: сначала проверьте состояние службы, последние записи журнала и свободное место. На это обычно уходит несколько минут, если у вас есть SSH-доступ и имя службы. Ниже — разбор для Ubuntu Server 24.04 LTS с Bash 5.2 и стандартными GNU-утилитами; в других дистрибутивах вывод и отдельные параметры могут отличаться.

Сначала найдите проект и службу

Представим типичную ситуацию: приложение работало до выкладки, а теперь возвращает 500. Ошибка может быть в самом приложении, в нехватке места или в том, что служба не запустилась. Команды ниже только читают состояние системы — они не меняют файлы и не перезапускают процессы.

До начала подготовьте:

• SSH-доступ к серверу;
• путь к каталогу проекта, если собираетесь осматривать файлы;
• имя systemd-службы приложения. Его можно узнать у коллеги или из конфигурации развёртывания;
• доступ через sudo, если обычному пользователю не видны системные журналы или каталоги.

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

Три источника сведений о сбое

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

Проверяем службу и читаем последние сообщения

Подставьте настоящее имя службы вместо my-app.service. Сначала запросите её состояние:

systemctl status my-app.service --no-pager

Смотрите на строки с состоянием и на недавние сообщения. Если служба остановлена или перезапускается, причина часто видна в выводе, но длинный журнал удобнее фильтровать отдельно. Команда ниже покажет последние 80 записей, относящихся к службе:

sudo journalctl -u my-app.service -n 80 --no-pager

Чтобы ограничить просмотр недавним интервалом, выполните:

sudo journalctl -u my-app.service --since "30 minutes ago" --no-pager

Не ищите только слово error: приложение может описывать сбой иначе. Для быстрой выборки сообщений с распространёнными маркерами используйте:

sudo journalctl -u my-app.service --since "30 minutes ago" --no-pager | grep -iE 'error|failed|exception' | tail -n 30

Пустой результат фильтра не доказывает, что журнал пуст: нужная запись могла не содержать этих слов. Сначала просмотрите журнал без grep. Если systemd сообщает, что такой службы нет, проверьте имя, а не меняйте его наугад.

Если приложение пишет в файлы

Некоторые приложения направляют сообщения не в журнал systemd, а в файл. Если вам известен его путь, например /var/log/my-app/error.log, последние строки можно вывести так:

sudo tail -n 80 /var/log/my-app/error.log

Путь здесь примерный: используйте тот, который задан именно в вашей конфигурации. Если файл большой и нужен только просмотр новых записей в реальном времени, подойдёт tail -f; остановить просмотр можно сочетанием Ctrl+C. Не отправляйте полный лог в общий чат: в нём могут оказаться адреса, данные запросов и другие чувствительные сведения.

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

Проверяем место и крупные каталоги

Если приложение не может записать файл, проверьте свободное место на файловой системе с проектом. Для корневого раздела используйте:

df -h /

Параметр -h выводит размеры в удобных единицах. Для проверки, не закончились ли свободные inode — служебные записи, нужные файловой системе для хранения файлов, — выполните:

df -i /

Много свободных гигабайт не гарантирует, что можно создать ещё один файл: закончившиеся inode тоже мешают записи. Если места мало, найдите крупные каталоги на корневой файловой системе:

sudo du -x -h --max-depth=1 /var | sort -h

Команда покажет размер каталогов первого уровня внутри /var; -x не даёт перейти на другие файловые системы. Проверка может занять время на сервере с большим количеством файлов. Самый крупный каталог — направление для дальнейшего поиска, а не автоматическое разрешение на удаление. Не запускайте rm по результатам такой проверки: сначала выясните, что именно занимает место и кто отвечает за эти файлы.

Когда выбирать каждый подход

• Служба не запущена или недавно перезапускалась. Начните с systemctl status и журнала systemd. Они связывают состояние процесса с сообщениями службы.
• Служба активна, но сайт выдаёт 500. Проверьте журнал за время сбоя и, если настроено, лог приложения. Смотрите не только на последнюю запись: полезен контекст до неё.
• Ошибки появились при записи, сборке или загрузке файлов. Сверьте df -h и df -i, затем найдите крупные каталоги через du. Эти команды покажут ограничения файловой системы, но не исправят их.

Что ломается при диагностике

Чаще всего мешает не сложность Linux, а неверное предположение о том, где искать.

• Unit my-app.service could not be found. Имя службы не совпало с установленным. Проверьте его у администратора или в конфигурации запуска.
• Permission denied. У пользователя нет прав читать файл или каталог. Для системного журнала и защищённых логов может понадобиться sudo; не меняйте права на файлы только ради чтения.
• Команда grep ничего не вывела. Это может означать лишь, что в выбранных строках нет заданных слов. Уберите фильтр и просмотрите журнал целиком.
• No such file or directory. Указан неверный путь или лог называется иначе. Найдите фактический путь в настройках приложения, а не создавайте файл с таким именем.
• df показывает место, а du — меньше. Причина может быть в удалённых, но ещё открытых процессом файлах или в другой точке монтирования. Не удаляйте дополнительные данные наугад: передайте результаты администратору и проверьте ситуацию отдельно.

Термин: inode. Это запись файловой системы о файле или каталоге: в ней хранятся его метаданные и сведения о расположении данных. Когда свободные inode заканчиваются, создать новый файл может не получиться даже при наличии свободного места на диске.

Что делать дальше

Сохраните время сбоя, вывод статуса службы и относящиеся к нему записи журнала. Затем сопоставьте их: служба упала, приложение записало ошибку или закончились ресурсы файловой системы? Следующий шаг зависит от найденной причины, поэтому не лечите все варианты перезапуском или удалением файлов. На сервере также полезно заранее уточнить, где приложение хранит логи и кто отвечает за их ротацию; настройка ротации — отдельная тема.