Проверка истории выключений и перезагрузок в Linux

Кратко

Это руководство показывает, как быстро и надежно получить историю выключений и перезагрузок на Linux-сервере через командную строку. Приведены несколько команд (last, tuptime, who, journalctl), сценарии устранения неполадок, чек-листы для ролей и краткий план действий при инциденте.

Важно: команды читают локальные журналы; они не всегда дают причину (например, аппаратный сбой или UPS). Используйте их как отправную точку для расследования.

Зачем это важно

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

Основные способы проверить историю выключений и перезагрузок

1. last — история логинов, выключений и перезагрузок

Команда last читает файл /var/log/wtmp и показывает время входов/выходов, а также записи shutdown/reboot:

last -x -F shutdown

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

last -x -F -n 3 shutdown

Аналогично для перезагрузок:

last -x -F reboot
last -x -F -n 3 reboot

Примечание: если wtmp повреждён или очищен, вывод может быть неполным.

2. tuptime — история и статистика аптаймов

tuptime хранит историю запусков и выключений в своём собственном формате и удобен для статистики по аптайму. Установка (скрипт установки):

bash < <(curl -Ls https://git.io/tuptime-install.sh)

После установки:

tuptime -t

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

tuptime -t | tail -3

Когда tuptime полезен: для статистики аптайма, оценки частоты непредвиденных перезапусков и накопления среднего времени работы между событиями.

3. who — время последней загрузки

Команда who с флагом -b показывает время последней загрузки системы:

who -b

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

4. journalctl — журнал systemd и список загрузок

Если система использует systemd, журнал systemd содержит записи о загрузках и выключениях. Для перечисления загрузок используйте:

journalctl --list-boots

Вывод нумерует записи (0 — текущая), показывает время старта и завершения. Для просмотра логов конкретной загрузки используйте идентификатор (например, -1, -2):

journalctl -b -1

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

Как интерпретировать результаты — простая методика (mini-methodology)

1. Соберите хронологию событий: используйте last/tuptime/who/journalctl, чтобы составить временную линию.
2. Сопоставьте время перезагрузки с системными журналами (journalctl -b N).
3. Проверьте последние обновления (apt/yum/dnf/zypper) — возможно, плановый перезапуск.
4. Проверьте аппаратные и питание: сообщения ACPI, syslog, и состояние UPS.
5. Если перезагрузка неожиданная — сохраните логи и снимите снимок конфигурации для дальнейшего анализа.

Критерии приёмки

• Получена полная хронология перезагрузок по last или journalctl.
• Для подозрительной перезагрузки есть журнал systemd (journalctl -b N) и, при возможности, снимок dmesg/uart.
• Логи экспортированы в безопасное место для последующего анализа.

Что можно сделать дальше — чек-листы по ролям

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

• Выполнить last -x -F reboot и last -x -F shutdown.
• Запустить journalctl –list-boots и просмотреть проблемную загрузку (journalctl -b -1).
• Сохранить логи: journalctl -b -1 > /tmp/boot-previous.journal.
• Проверить обновления пакетов и cron/ansible/chef runs.

Чек-лист для девопса

• Проверить CD/CI pipeline на предмет автоматических перезагрузок.
• Проверить конфигурации конфигурационного менеджера на триггеры reboot.
• Сверить время развертываний с временной шкалой перезагрузок.

Чек-лист для службы безопасности

• Проверить аутентификацию и sudo-логи на предмет команд reboot/shutdown.
• Проверить доступы и интеграции, которые могли инициировать перезапуск.
• Соблюдать процедуры сохранения и передачи логов для инцидент-анализа.

Инцидентный план действий (Runbook)

1. Зафиксировать время инцидента (по last или tuptime).
2. Немедленно сохранить журналы (journalctl -b -1 > /var/tmp/prev-journal.log).
3. Проверить dmesg на наличие сообщений о критических ошибках: dmesg | tail -50.
4. Проверить аппаратуру и питание: ipmitool, логи контроллера RAID, состояние UPS.
5. Если причина неочевидна — перевести систему в режим повышенной логируемости и установить мониторинг (скрипты heartbeat, node-exporter + alerts).
6. Откат: если перезагрузка была вызвана изменением конфигурации, откатьте последний релиз и зафиксируйте состояние.

Пример команд для сбора артефактов при расследовании:

journalctl --list-boots > /var/tmp/journal-list.txt
journalctl -b -1 > /var/tmp/journal-previous.log
last -x -F > /var/tmp/last-full.log
tuptime -t > /var/tmp/tuptime-history.txt
dmesg > /var/tmp/dmesg.log

Важно: не очищайте журналы до завершения расследования.

Когда эти методы не помогут (ограничения)

• Если файл wtmp был очищен или повреждён — last не покажет старые события.
• Если systemd не используется или журнал ротации настроен агрессивно — journalctl может не содержать старых записей.
• Команды не дадут «причину» аппаратных сбоев (например, сбой блока питания). Для этого нужны аппаратные логи и мониторинг датчиков.

Советы по безопасности и приватности

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

Быстрая проверка — чек-лист для первой диагностики (5 минут)

• last -x -F -n 10 reboot
• journalctl –list-boots
• who -b
• dmesg | tail -20
• Проверить cron и упаковочные менеджеры на недавние операции

Примеры ошибок и альтернативные подходы

• Если last показывает «wtmp begins …» и недостаточно данных, попробуйте восстановить логи из резервной копии или используйте tuptime, если он устанавливался ранее.
• Если systemd-journald ротация очищает логи — настройте централизованный сбор (rsyslog/Graylog/ELK) для длительного хранения.

Короткий словарь

• wtmp — системный файл, где хранится история входов/выходов.
• journalctl — утилита для просмотра журналов systemd.
• tuptime — утилита для статистики времени работы системы.

Часто задаваемые вопросы

Q: Можно ли узнать причину аварийной перезагрузки только по last?
A: Нет — last даёт таймстемпы, но причина чаще всего в системных логах (journalctl -b N), dmesg или аппаратных логах.

Q: Нужно ли хранить логи дольше?
A: Да. Для расследований рекомендуется централизованное хранение логов минимум на несколько недель или месяцев в зависимости от политики организации.

Q: Что быстрее — tuptime или last?
A: last доступен по умолчанию и даёт мгновенную информацию, tuptime удобен для статистики и долгосрочного анализа.

Итоги

• Используйте last, tuptime, who и journalctl как взаимодополняющие инструменты.
• Составьте хронологию событий и сопоставьте её с системными логами.
• Настройте централизованный сбор логов и политику хранения, чтобы упростить расследования в будущем.

Краткие рекомендации: при подозрительных перезагрузках сразу сохраните журналы, проверьте dmesg и аппаратные логи, проанализируйте недавние изменения в конфигурации или развертываниях.