Сайт не открывался, по SSH не подключиться, а через несколько минут всё заработало само. Или сервер пришлось перезагружать из панели провайдера, и теперь непонятно, что это было. Первый вопрос в такой ситуации — не «как починить», а «что произошло»: сервер завис, его выключили, его перезагрузил провайдер или он всё это время работал, но до него не доходила сеть. От ответа зависит, что делать дальше.
Коротко: время и характер сбоя восстанавливаются по трём источникам — записям о загрузках (last -x, journalctl --list-boots), журналу предыдущей загрузки (journalctl -b -1) и логу веб-сервера. Если штатного выключения не было, а в журнале ядра нет ни OOM, ни ошибок дисков, — почти всегда это внешняя причина: жёсткий сброс виртуальной машины или проблема на стороне провайдера.
Что проверить в первую минуту
Сначала убедитесь, была ли вообще перезагрузка. Если сервер не перезапускался, искать надо в сети, а не внутри системы.
uptime -s
who -b2026-11-04 12:16:03
system boot 2026-11-04 12:16Обе команды показывают время текущей загрузки. Если оно раньше момента, когда Вы заметили недоступность, сервер не перезагружался — переходите к разделу про сеть.
Затем список прошлых загрузок с полными датами:
last -x -F reboot shutdownreboot system boot 6.1.0-27-amd64 Wed Nov 4 12:16:03 2026 still running
reboot system boot 6.1.0-27-amd64 Mon Oct 19 03:12:44 2026 - crash (16+09:03)
shutdown system down 6.1.0-27-amd64 Mon Oct 19 03:12:30 2026 - Mon Oct 19 03:12:44 2026 (00:00)Здесь важно слово crash: так last помечает загрузку, после которой не было записи о штатном выключении (shutdown system down). Система не завершала работу сама — её сбросили, у неё пропало питание или она зависла и была перезапущена. Строка shutdown перед загрузкой, наоборот, говорит о нормальном выключении или перезагрузке.
В Debian 13 команд last и lastb больше нет: по примечаниям к выпуску их заменяет wtmpdb last из пакета wtmpdb (нужен и libpam-wtmpdb). Ключи -x и -F там те же. В Debian 12, Ubuntu 22.04/24.04 и AlmaLinux 9 last на месте. Если ни того ни другого нет, хватит журнала systemd — он даже точнее.
Журнал systemd: когда сервер перестал писать логи
Я обычно начинаю с этой команды — она сразу показывает время последней записи перед сбоем:
journalctl --list-bootsIDX BOOT ID FIRST ENTRY LAST ENTRY
-1 5c1e0a7d9b2f4e6a8c3d1f0b7e9a2c45 Mon 2026-10-19 03:12:44 MSK Wed 2026-11-04 12:07:28 MSK
0 b84f2d6e1a9c4c07a5e3f8d2c6b1e490 Wed 2026-11-04 12:16:03 MSK Sat 2026-11-07 10:41:12 MSKКолонка LAST ENTRY у загрузки -1 — последняя строка, которую система успела записать. Между ней и FIRST ENTRY текущей загрузки и лежит окно сбоя. Если в списке только одна строка, журнал не сохраняется между перезагрузками: при Storage=auto он пишется на диск, только если существует каталог /var/log/journal. Включите хранение заранее (об этом ниже), иначе в следующий раз смотреть будет нечего.
Дальше — последние строки предыдущей загрузки:
journalctl -b -1 -n 50 --no-pagerПри штатной перезагрузке хвост выглядит узнаваемо:
Oct 19 03:12:30 web1 systemd[1]: Reached target reboot.target - System Reboot.
Oct 19 03:12:30 web1 systemd[1]: Shutting down.
Oct 19 03:12:30 web1 systemd-shutdown[1]: Syncing filesystems and block devices.
Oct 19 03:12:30 web1 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Oct 19 03:12:30 web1 systemd-journald[312]: Received SIGTERM from PID 1 (systemd-shutdow).
Oct 19 03:12:30 web1 systemd-journald[312]: Journal stoppedЕсли провайдер «нажал кнопку питания» мягко (ACPI), перед этим будет строка systemd-logind[…]: Power key pressed short. Если же журнал обрывается на обычной рабочей записи — cron, PHP-FPM, что угодно — значит, система до выключения не дошла.
Ядро: OOM, зависания, ошибки дисков
Сообщения ядра предыдущей загрузки отдельно, с фильтром по типичным признакам беды:
journalctl -b -1 -k --no-pager | grep -Ei 'out of memory|oom|panic|blocked for more than|soft lockup|i/o error|hardware error'Oct 28 21:48:42 web1 kernel: Out of memory: Killed process 2143 (mysqld) total-vm:2849532kB, anon-rss:1203448kB, file-rss:0kB, shmem-rss:0kB, UID:110 pgtables:3120kB oom_score_adj:0
Oct 28 21:53:10 web1 kernel: INFO: task php-fpm8.2:3391 blocked for more than 120 seconds.Out of memory: Killed process— кончилась память, ядро убило процесс. Сам по себе OOM сервер обычно не роняет, но перед ним система может долго «молотить» и не отвечать.blocked for more than N seconds— процесс не дождался диска. На виртуалке это часто проблемы хранилища у провайдера.soft lockup— процессор долго не получал управления; на VDS бывает при перегрузке хоста.I/O error— ошибки чтения или записи на диск.
Пустой результат — тоже результат. Учтите только, что при панике ядра или полном зависании запись на диск прекращается, и последних сообщений в журнале может не быть вовсе. Если сервер висел с паникой, видно это обычно только в консоли провайдера. О разборе одной из таких паник — в статье Kernel panic — not syncing: Attempted to kill init.
Кто выключал
Если выключение было штатным, проверьте, кто был в системе и кто запускал команды через sudo:
last -F | head -20
journalctl -b -1 _COMM=sudo --no-pager | tail -20Лог nginx: когда перестали приходить запросы
Журнал системы показывает, когда сервер замолчал, а лог веб-сервера — когда перестали приходить посетители. Число запросов по минутам хорошо показывает разрыв:
awk '{print $4}' /var/log/nginx/access.log | cut -c2-18 | uniq -c | tail -20 38 04/Nov/2026:12:05
41 04/Nov/2026:12:06
22 04/Nov/2026:12:07
9 04/Nov/2026:12:16
35 04/Nov/2026:12:17Если сбой был давно, лог мог уйти в ротацию — смотрите access.log.1 или сжатые файлы через zcat. Сравнивая логи, проверьте, что часы на сервере идут верно: при расхождении времени выводы будут ложными (см. синхронизация времени в виртуальных машинах).
Как различить: завис, выключили, перезагрузил провайдер, пропала сеть
| Что видно | Что это значит | Что делать |
|---|---|---|
| Время загрузки не менялось, журнал за время недоступности непрерывный, в access.log провал | Сервер работал, пропала сеть: у провайдера, в маршрутизации или из-за фаервола | Проверить фаервол и сетевые сообщения в журнале, написать провайдеру с точным временем |
Перед загрузкой — Reached target reboot.target, Journal stopped, в last есть shutdown |
Штатная перезагрузка или выключение | Искать, кто или что её запустило: sudo, автообновления, панель |
Есть Power key pressed short. |
Выключение «кнопкой» из панели провайдера | Проверить журнал действий в панели и уведомления провайдера |
Журнал обрывается на обычной записи, crash в last, ошибок ядра нет |
Жёсткий сброс: провайдер, сбой хоста, пропало питание | Запрос в поддержку с точным временем последней записи и загрузки |
Перед обрывом — OOM, blocked for more than, soft lockup, I/O error |
Система зависла от нехватки памяти или проблем с диском | Разбирать память и диски; при ошибках хранилища на VDS — к провайдеру |
Полезная проверка после жёсткого сброса — не изменились ли ресурсы машины. Строка ядра Memory: пишется при каждой загрузке:
journalctl -b -1 -k --no-pager | grep -m1 'Memory:'
journalctl -b 0 -k --no-pager | grep -m1 'Memory:'
nprocЕсли памяти или процессоров стало больше, провайдер менял тариф, а для этого машину часто перезапускают.
Как проверить сервер снаружи, пока он недоступен
Самое ценное — проверить сервер в момент проблемы, пока его никто не перезагрузил. С другой машины, например со второго сервера:
ping -c 4 178.72.152.47
nc -vz -w 3 178.72.152.47 22
nc -vz -w 3 178.72.152.47 443
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 10 https://www.example.com/Connection to 178.72.152.47 22 port [tcp/ssh] succeeded!Если порты отвечают, а сайт нет — проблема в веб-сервере или PHP, сервер жив. Если не отвечает ничего, проверьте из нескольких мест: сервисы проверки доступности (например, check-host.net) делают ping и TCP-проверку из десятка стран. Сервер недоступен отовсюду — проблема в нём или в сети провайдера. Недоступен только из части мест — дело в маршрутах или фильтрации по пути.
Если у Вас есть другой сервер в той же подсети, у того же провайдера, можно проверить ещё глубже — ответ на ARP:
ping -c 2 178.72.152.47
ip neigh show 178.72.152.47178.72.152.47 dev eth0 FAILEDСостояние FAILED значит, что машина не ответила даже на ARP-запрос. Фаервол на ARP не влияет, поэтому это не закрытый порт, а выключенная или зависшая машина или оборванный канал до неё. REACHABLE или STALE с MAC-адресом при молчащем ping указывает на фильтрацию. Оговорка: метод работает, только если машины действительно в одном сегменте сети; в некоторых облаках на ARP отвечает сама сеть провайдера.
Случай из практики
VDS с сайтами стал недоступен из всех точек проверки примерно на девять минут, затем заработал сам. В журнале systemd последняя запись предыдущей загрузки — 12:07:28, последний запрос в access.log nginx — 12:07:31, новая загрузка — 12:16. Записей штатного выключения нет, last -x показал crash. Ни OOM, ни зависших задач, ни ошибок ввода-вывода в журнале ядра не было: система работала нормально и просто оборвалась.
Ответ нашёлся в строке Memory:: после загрузки у машины оказалось вдвое больше памяти — 4 ГБ вместо 2. Провайдер менял тариф и сделал это с жёсткой перезагрузкой, без корректного выключения гостевой системы. Вывод из таких данных — это гипотеза, и её надо подтвердить: в журнале действий панели или вопросом в поддержку с точным временем.
Как не гадать в следующий раз
- Внешний мониторинг доступности. Проверка ping, порта 443 и страницы сайта раз в минуту с другой машины или из стороннего сервиса. Тогда момент падения и восстановления известен точно, а не по логам задним числом.
- Сохраняемый журнал. Создайте
/var/log/journalили задайтеStorage=persistentв файле в/etc/systemd/journald.conf.d/, затемsystemctl restart systemd-journald. Подробности — в man journalctl и journald.conf. - Поведение при панике. Проверьте
sysctl kernel.panic: значение0значит, что после паники машина будет висеть до ручного сброса. Для сбора дампа при панике есть kdump (пакетkdump-toolsв Debian и Ubuntu, службаkdumpв AlmaLinux). - Запас по памяти. Если причиной был OOM, ограничьте потребителей: число процессов PHP-FPM и буферы базы данных (см. оптимизация MySQL 8 и MariaDB).
- Уведомления провайдера. Включите письма о плановых работах и изменениях тарифа, проверьте, на какой адрес они приходят.
Частые вопросы
Почему journalctl —list-boots показывает только одну загрузку?
Журнал хранится в памяти (/run/log/journal) и пропадает при перезагрузке. При настройке Storage=auto он пишется на диск, только если есть каталог /var/log/journal. Включите постоянное хранение — прошлый сбой это не вернёт, но следующий будет виден.
Что значит crash в выводе last?
Для загрузки нет парной записи о штатном выключении: система не завершала работу сама. Причины бывают разные — жёсткий сброс, отключение питания, зависание с последующим перезапуском. Сам crash не говорит, какая именно; это видно по журналу ядра и данным провайдера.
Сервер не перезагружался, но был недоступен. Где искать?
Сравните журнал и access.log за это время. Если журнал писался непрерывно, а запросов не было, проблема была в сети: проверьте сообщения о сетевом интерфейсе в journalctl -k, правила фаервола и спросите провайдера, не было ли работ или атаки на сеть.
Можно ли узнать причину, если в журнале ничего нет?
Изнутри — только косвенно: по времени обрыва, отсутствию записей о выключении и изменениям ресурсов машины. Точный ответ даёт провайдер: у него есть журнал действий с виртуальной машиной и данные о состоянии хоста. Обращаясь в поддержку, указывайте IP сервера, время последней записи в журнале и время новой загрузки.