LINUX.ORG.RU
ФорумAdmin

Debian несанкционированно перезагружается в 3 ночи - как выяснить причину?

 ,


1

4

Пару недель назад Debian 12 сервер стал несанкционированно перезагружаться ровно в 3 часа ночи. Первое время не каждый день, последние несколько дней - каждый день. Сначала подумал, что дело, возможно, в аппаратном сбросе, например через ИБП - но учитывая точное время перезагрузки - складывается впечатление, что перезагрузка программная.

В crontab нет никаких записей с перезагрузкой.

В логах systemd нет никакой информации указывающей на причины перезагрузки, вот пару примеров вывода journalctl соответствующего времени:

May 06 01:17:02 debi9 CRON[15085]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 06 01:17:02 debi9 CRON[15086]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 06 01:17:02 debi9 CRON[15085]: pam_unix(cron:session): session closed for user root
May 06 02:17:01 debi9 CRON[28717]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 06 02:17:01 debi9 CRON[28718]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 06 02:17:01 debi9 CRON[28717]: pam_unix(cron:session): session closed for user root
-- Boot c6a5eac4d88c464592b8a3f493fc39ff --
May 06 03:00:35 debi9 kernel: microcode: microcode updated early to revision 0x11d, date = 2023-08-29
May 06 03:00:35 debi9 kernel: Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
May 06 03:00:35 debi9 kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=UUID=320c1ce7-c162-46bc-aa90-81ecafb4ecdb ro quiet split_lock_detect=off
May 06 03:00:35 debi9 kernel: x86/tme: not enabled by BIOS
May 06 03:00:35 debi9 kernel: x86/split lock detection: disabled
May 06 03:00:35 debi9 kernel: BIOS-provided physical RAM map:
May 07 01:41:11 debi9 systemd[1]: Starting man-db.service - Daily man-db regeneration...
May 07 01:41:11 debi9 systemd[1]: man-db.service: Deactivated successfully.
May 07 01:41:11 debi9 systemd[1]: Finished man-db.service - Daily man-db regeneration.
May 07 02:17:01 debi9 CRON[295327]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 07 02:17:01 debi9 CRON[295328]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 07 02:17:01 debi9 CRON[295327]: pam_unix(cron:session): session closed for user root
-- Boot bd603611c06946c5a44c30660beb7bf8 --
May 07 03:00:39 debi9 kernel: microcode: microcode updated early to revision 0x11d, date = 2023-08-29
May 07 03:00:39 debi9 kernel: Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
May 07 03:00:39 debi9 kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=UUID=320c1ce7-c162-46bc-aa90-81ecafb4ecdb ro quiet split_lock_detect=off
May 07 03:00:39 debi9 kernel: x86/tme: not enabled by BIOS
May 07 03:00:39 debi9 kernel: x86/split lock detection: disabled
May 07 03:00:39 debi9 kernel: BIOS-provided physical RAM map:

Есть подозрение, что проблема как-то связана с ядром. За день до начала этих перезагрузок было проведено обновление системы с установкой ядра версии 6.1.0-18 с тех пор появились эти перезагрузки в 3 часа ночи, но не ежедневно. Несколько дней назад ядро было обновлено до 6.1.0-20 - с тех пор перезагрузки случаются каждую ночь.

Поиск обнаружил похожую тему: «PVE automatically reboots at 3 a.m. every day»: https://forum.proxmox.com/threads/pve-automatically-reboots-at-3-a-m-every-da... - симптомы очень похожи, но там нет никакого решения, тема заброшена.

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

(в качестве же решения пока приходит в голову только даунгрейд до предыдущей версии ядра - но это так себе решение)

Удалось добраться до сервера: воспроизвел проблему после изменения времени на 2:50 с включенным монитором - выглядело будто это хардрезет.

Обновил биос (была версия F3 до, после обновления - F10) после обновления биоса сервер не завёлся. Светодиод и вентиляторы заработали - но на монитор - никакой картинки. Выключили и включил - не заработал. Снова выключили и включил - на четвертый раз - заработал. Попробовал с обновленным биосом воспроизвести проблему: 5 раз - ставил на 2:55 - ждал 5 минут - перезагрузок не происходило. Обрадовавшись уехал восвояси, этой же ночью проблема снова воспроизвелась. Только теперь проблема проявляется не перезагрузкой - а как «выключение»: хотя физически сервер работает, светится, вентиляторы крутятся, но биос и система не стартуют. Если выключить и включить кнопкой - запускается.

На мой взгляд, это говорит о том, что это какая-то специфическая проблема материнской платы. Модель: GIGABYTE Z790 UD

Модель этой материнской платы подвержена уязвимости, обнаруженной в прошлом году: https://habr.com/ru/news/739118 https://eclypsium.com/wp-content/uploads/Gigabyte-Affected-Models.pdf По-идее, обновление биоса должно было бы решить проблему, если причина в этом - но, похоже, дело не в этом.

Kircher
() автор топика
Последнее исправление: Kircher (всего исправлений: 1)
Ответ на: комментарий от Kircher

после обновления биоса сервер не завёлся. Светодиод и вентиляторы заработали - но на монитор - никакой картинки. Выключили и включил - не заработал. Снова выключили и включил - на четвертый раз - заработал.

На мой взгляд это говорит о проблеме с железом или ошибках firmware.

anonymous
()
Ответ на: комментарий от Kircher

Обновил биос (была версия F3 до, после обновления - F10) после обновления биоса сервер не завёлся. Светодиод и вентиляторы заработали - но на монитор - никакой картинки. Выключили и включил - не заработал. Снова выключили и включил - на четвертый раз - заработал.

надо было не выключать, а подождать, современные биосы бывают очень задумчивы при первом запуске, видимо соединяются с АНБ и сливают им твои данные

anonymous
()
Ответ на: комментарий от Kircher

Потому что проблема впервые появилась после пришедшего обновления ядра. До этого был бесперебойный аптайм более полугода.

Я имел ввиду, почему откатить плохой вариант.

AS ★★★★★
()
Ответ на: комментарий от Kircher

Возможно стоит посмотреть логи Загрузок раздел инициализации оборудования, до и после обновления. Рано вы уехали) Стоит пробовать livecd с разными версиями ядер, это если оборудование позволит. Это до дальнейших манипуляций с обновлениями и прочим. Дальше я бы проверил версии firmware и сравнил их с ожидаемыми, хотя стоковые версии не так просто найти. После - свап оборудования если возможно. Бузер есть? сигнал ок был? Есть ли диагностическая карта? Если нет то так-же свап. Еще стоит посмотреть биос на предмет ведения логов или такой возможности, выключить контройлеры периферии если они не используются - они могут быть причиной долгих стартов. Насчет уязвимости, пробовать стартануть с выключенной сетью. На моей практике пк не стартовал с определенной видеокартой (небыло сигнала ок) в UEFI режиме - или другая видяха или легаси мод.

alhimik
()