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

Таймеры systemd может? Не знаю какой может в 3 ночи. Logrotate например в 1 час срабатывает.

даунгрейд до предыдущей версии ядра - но это так себе решение

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

Посмотрел systemctl list-timers - нет ничего ровно на 3 часа ночи, когда происходит перезагрузка:

NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES                     
Wed 2024-05-08 14:31:29 MSK 11min left    Wed 2024-05-08 13:31:47 MSK 48min ago    anacron.timer                anacron.service
Wed 2024-05-08 17:57:39 MSK 3h 37min left Wed 2024-05-08 00:06:39 MSK 14h ago      apt-daily.timer              apt-daily.service
Thu 2024-05-09 00:00:00 MSK 9h left       -                           -            dpkg-db-backup.timer         dpkg-db-backup.service
Thu 2024-05-09 00:00:00 MSK 9h left       Wed 2024-05-08 00:00:12 MSK 14h ago      logrotate.timer              logrotate.service
Thu 2024-05-09 03:23:05 MSK 13h left      Wed 2024-05-08 13:48:07 MSK 31min ago    man-db.timer                 man-db.service
Thu 2024-05-09 06:32:47 MSK 16h left      Wed 2024-05-08 09:42:07 MSK 4h 37min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Thu 2024-05-09 09:26:07 MSK 19h left      Wed 2024-05-08 09:26:07 MSK 4h 53min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2024-05-12 03:10:45 MSK 3 days left   Sun 2024-05-05 03:10:54 MSK 3 days ago   e2scrub_all.timer            e2scrub_all.service
Mon 2024-05-13 00:31:34 MSK 4 days left   Mon 2024-05-06 00:22:54 MSK 2 days ago   fstrim.timer                 fstrim.service

9 timers listed.

В прошлом году сталкивался с внезапными перезагрузками Дебиан 11 из-за дефекта блока питания. Судя по показанному логу - перезагрузка именно что внезапная,а не штатный шатдаун с остановкой всех сервисов. Так что это больше всего похоже именно на аппаратный глюк.

По логу видно, что перезагрузка внезапная.

Как насчёт варианта, что в это время «мигает» электричество? Тогда ищите проблему в работе ИБП, либо при его отсутствии – в том, откуда запитывается машина.

Сначала подумал, что дело, возможно, в аппаратном сбросе, например через ИБП

Для начала надо проверить, исправен ли вообще ИБП. А то может он только делает вид, что работает.

Как насчёт варианта, что в это время «мигает» электричество? Тогда ищите проблему в работе ИБП

Этот вариант крайне маловероятен. На том же ИБП висит еще один сервер и роутер - с ними всё в порядке, работают без остановки.

Также, на программную причину указывает точное время перезагрузки: 3:00:00 - все несанкционированные перезагрузки за эти недели, судя по логам, случались исключительно в это время, ни минутой раньше или позже.

Пришла в голову идея для уточнения попробовать программно изменить днём время на сервере на 2:55:00 - и посмотреть, перезагрузится ли после этого, а потом изменить время на некорркетное и посмотреть будет ли перезагружаться и если да - то во сколько по корректному времени (прямо сейчас не могу этого сделать - в рабочее время сервер используется людьми).

Что в cron в 3 часа ночи?

Сколько hdd в сервере? Уходят ли они в сон (параметр Load Cycle Count в smartctl)?

Что в cron в 3 часа ночи?

Ничего.

Сколько hdd в сервере? Уходят ли они в сон (параметр Load Cycle Count в smartctl)?

upd: Нет hdd. Используются только NVMe и SSD.

Где сервер стоит? Туда в 3 ночи пустят? Это самый простой вариант наверно, подключить монитор и посмотреть что происходит в этот момент. Ну и на состояние ибп тоже.

еще один сервер

Если ещё один сервер с линуксом, можно настроить netconsole, на обоих, иногда хорошо помогает ловить глюки железа.

Как может быть связано обновление ядра с внезапными выключениями? Если только что-то залезло в инитрд? Зловред? Но это я так, пальцем в небо.

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

Дополню совет, если есть ilo, то имеет смысл настроить вывод сообщений загрузки в виртуальную последовательную консоль и подключится к ilo каким нибудь другим компом хоть по ssh.

В каком часовом поясе сервер? 3 часа ночи по московскому времени это аккурат полночь UTC. Гугли про проблемы с полуночью, может найдешь что.

Может быть у вас на одной из фаз уличное освещение и реле контроля фаз перебрасывает нагрузку для выравнивания перекоса. Что делать? Сядьте на другую фазу.

Осмотри с пристрастием материнскую плату на предмет умирающих компонентов. В частности конденсаторов.

Уборщица?

стабильно же с точностью до минуты? ну тогда какие вопросы?

Пришла в голову идея для уточнения попробовать программно изменить днём время на сервере на 2:55:00 - и посмотреть, перезагрузится ли после этого,

Попробовал только что (21:00 по МСК), выставил время на 2:50 следующего дня, в 3:00 системного времени произошла перезагрузка:

# hwclock --show
2024-05-09 02:53:20.947914+03:00
root@debi9:/# client_loop: send disconnect: Broken pipe

В логах всё то же самое:

May 09 02:43:33 debi9 anacron[175684]: Normal exit (2 jobs run)
May 09 02:43:33 debi9 systemd[1]: anacron.service: Deactivated successfully.
May 09 02:50:18 debi9 kernel: perf: interrupt took too long (3961 > 3957), lowering kernel.perf_event_max_sample_rate to 50250
May 09 02:53:20 debi9 sudo[180330]:     root : TTY=pts/2 ; PWD=/home/user ; USER=root ; COMMAND=/usr/sbin/hwclock --show
May 09 02:53:20 debi9 sudo[180330]: pam_unix(sudo:session): session opened for user root(uid=0) by user(uid=0)
May 09 02:53:20 debi9 sudo[180330]: pam_unix(sudo:session): session closed for user root
-- Boot bfdefb35191b478ea93d8a1185ea00bd --
May 09 03:00:36 debi9 kernel: microcode: microcode updated early to revision 0x11d, date = 2023-08-29
May 09 03:00:36 debi9 kernel: Linux version 6.1.0-21-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 PREEMP>
May 09 03:00:36 debi9 kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 root=UUID=320c1ce7-c162-46bc-aa90-81ecafb4ecdb ro quiet split_lock_detect=off
May 09 03:00:36 debi9 kernel: x86/tme: not enabled by BIOS
May 09 03:00:36 debi9 kernel: x86/split lock detection: disabled
May 09 03:00:36 debi9 kernel: BIOS-provided physical RAM map:

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

Наверное, попробую теперь то же самое, но со старой версией ядра, с которой этой проблемы не было (6.1.0-17).

В каком часовом поясе сервер? 3 часа ночи по московскому времени это аккурат полночь UTC. Гугли про проблемы с полуночью, может найдешь что.

Да, часовой пояс UTC+03:00. Перезагрузка определённо программная. Странно что срабатывает в полночь по UTC, а не полночь по системному часовому поясу.

У тебя случаем не включены автоматические обновления или участие в программе тестирования?

Что отвечал при установке?

Автоматические обновления не включены и в тестировании не принимаю участие.

Наверное, попробую теперь то же самое, но со старой версией ядра, с которой этой проблемы не было (6.1.0-17).

С ядром 6.1.0-17 поставил время на 2:50 завтрашнего дня (получается «откатив немного назад» системное время) - перезагрузка не произошла. Решил на всякий случай еще поставить 2:50 послезавтра - и перезагрузка всё-таки случилась. Значит причина не в ядре. Причина в чем-то ещё.

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

поставил время на 2:50 завтрашнего дня (получается «откатив немного назад» системное время) - перезагрузка не произошла. Решил на всякий случай еще поставить 2:50 послезавтра - и перезагрузка всё-таки случилась. Значит причина не в ядре. Причина в чем-то ещё.

Итак, оно запоминает время. Значит это точно какой-то таймер.

Если не таймер systemd и не крон, то что еще может? Где-то в /var должно быть что-то, в чем хранится метка времени.

Чо-то я подумал. Вряд ли где-то кроме systemd и крон прям сидят таймеры.

Я бы последовательно отключал все daily задачи в systemd и кроне и смотрел, на каком проблема исчезнет. Для начала можно попробовать вообще отключить крон.

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

Согласен. Но продолжу утверждать что это проблема не линуксовая,а железа,точнее его встроенного ПО (BIOS). Если бы была именно линуксовая(где-нибудь в конфигах прописанная) перезагрузка то был бы нормальный шатдаун с остановкой сервисов и отмонтированием файловых систем.

Предложу еще посмотреть на сонный таймер в CMOS. Сейчас не вспомню линуксовую команду которая показывает его значение,но она существует. Я когда у себя копал причину перезагрузок - находил ее и смотрел не связано ли это с срабатыванием сонного таймера. Также имеет смысл повыключать в BIOS Setup всякие «глубоко сонные» состояния. Так как это круглосуточно работающий сервер то они ему не нужны, а вот глюки вызывать вполне могут. Причем бывает что глючные не все а только какие-нибудь.

Также поддерживаю идею подключить консоль на другую машину. Проще всего через ком-порт если он есть на плате. Тогда на другой машине потребуется всего лишь терминал с портом работающий (minicom например). Сохранять историю вывода он умеет.

Все виды гибернации что я могу вспомнить программные или программно аппаратные. Попробуйте дать нагрузку на диски, может с ними что или с шиной PCIE, например экономия энергии. Складывается ощущение что уже нет их (дисков) когда система выключается.

Все виды гибернации что я могу вспомнить программные или программно аппаратные.

Это когда они правильно работают. А правильность зависит по большей части от степени кривости таблиц ACPI,особенно DSDT. При этом кривая DSDT это достаточно частое явление. Вопрос лишь в степени этой кривости и совместимости этой кривости с ядром. И вот там бывает что при попытке уйти в сон вместо этого случается именно что reset.

Например в компе,с которого я это пишу, наблюдается некоторая странность. Когда был свежепоставленный Дебиан 11 то и выключение и перезагрузка штатными средствами работали правильно. Но где-то в начале прошлой осени приехало обновление ядра. Точно не могу сказать с какого на какое точно так как это не важный сервер и я за ним не особо внимательно слежу. И теперь нередко после выполнения shutdown система останавливается,экран гаснет,но питание не выключается. И такое примерно 1:10 к нормальным выключениям. А вот команда reboot стала перезапускать систему так что вывода на экран нет. Сама система загружается но отсутствует картинка. Это я пишу к тому,что таки да - в ядре с какого-то момента что-то связанное с ACPI опять сломали.

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

Я еще с подозрением смотрел на e2scrub_all.timer в связи с этим.

Однако судя по выводу команды, он вызывается не раз в сутки, значит причиной быть не может.

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

Согласен. Но почему тогда глюк происходит в одно и то же время,да еще и повторяемый при переустановке часов? Сбой в драйвере логично ожидать под существенной нагрузкой,а не в три часа ночи когда ожидать ее маловероятно. Ну только если какое-нибудь locatedb в это время перестраивается(нафиг ненужное в большинстве случаев) и сильно нагружает ФС.

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

Физически до сервера пока так и не удалось добраться. Как доберусь - переставлю время на 2:55 - и буду смотреть на экран, а также в планах обновление биоса.

Пока же через крон сделал вот такой «time shift crutch» («костыль временного сдвига»):

# crontab -l
58 2 * * * /root/timeshift.sh
9 3 * * * /root/timesync.sh
# cat timeshift.sh 
#!/bin/sh
systemctl stop systemd-timesyncd
timedatectl set-time '03:05:00'
# cat timesync.sh 
#!/bin/sh
systemctl start systemd-timesyncd

В 2:58 останавливается синхронизация времени по сети и время изменяется на 3:05, а в 3:09 возобновляется синхронизация.

Как известно, нет ничего более постоянного, чем временное. =)

systemd

глобально и надёжно, ну-ну.

В pstore что-нибудь есть? Системда ж, вроде, должна уметь читаемый лог собирать из тамошних кусочков.

А у тебя там таймзона правильная, а то вдруг он не по твоим часам живёт?

Ещё может это у тебя сосед по стойке начинает жрать питание?

В pstore что-нибудь есть?

В /sys/fs/pstore - пусто.

При этом:

# systemctl status systemd-pstore
○ systemd-pstore.service - Platform Persistent Storage Archival
     Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2024-05-14 09:17:56 MSK; 8h ago
             └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met
       Docs: man:systemd-pstore(8)

May 14 09:17:55 debi9 systemd[1]: systemd-pstore.service - Platform Persistent Storage Archival was skipped because of an unmet condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore).

(09:17 - это время последней «ручной» перезагрузки, то есть санкционированной)

«ConditionDirectoryNotEmpty» - это что, получается, надо туда файл какой-то положить, что бы systemd-pstore активным стал, правильно понимаю?

А у тебя там таймзона правильная, а то вдруг он не по твоим часам живёт?

Таймзона правильная, MSK (UTC+3), но как здесь ранее отметили: перезагрузки эти происходят в 00:00 по UTC-0.

Ещё может это у тебя сосед по стойке начинает жрать питание?

Это исключено, учитывая, что при умышленном изменении системного времени - перезагрузка всё равно происходит.

При чём, как позже выяснилось, в зависимости от того, как устанавливать системное время: date и hwclock - могут одновременно показывать разное время. Перезагрузка происходит именно по hwclock. То есть корректнее было бы сказать, что перезагрузка происходит почему-то по хардварному UTC-0, хотя судя по выводу там время хранится в +03:00. Синхронизировать системное с железным временем можно:

hwclock --systohc

точнее его встроенного ПО (BIOS).

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

Этот вариант крайне маловероятен. На том же ИБП висит еще один сервер и роутер - с ними всё в порядке, работают без остановки.

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

esc при выключении нажми, у меня так пару месяцев назад kernel panic попался хитрый при выключении, который тоже экран выключил вроде как, а комп гудит, жмакнул esc любовался на замечательные буковки и циферки, кстати произошло в ubuntu после очередного обновления ядра. Акция была разовой, больше не повторялось. Что там было так и не понял, т.к. всё невразумительно было.

Смотрел какие службы начинают работать в этот момент? Может какая-то джоба на битый сектор натыкается?

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

Почему?

Время перезагрузки совпадает до секунд, или плавает всё же? А то, может, время GMT+3, запускается какой-нибудь logrotate и из-за перегрева/пыли/вспухших кондёров/разное сервер ребутится?

Где сервер стоит? Туда в 3 ночи пустят? Это самый простой вариант наверно, подключить монитор и посмотреть что происходит в этот момент.

Может и без монитора проблему поймать получится, охрана и другие уборщицы... :)

Этот вариант крайне маловероятен. На том же ИБП висит еще один сервер и роутер - с ними всё в порядке, работают без остановки.

Не факт. У меня было такое: на бесперебойнике 3 сервера, при «мигании» электричества один сервер перезагружался из-за плохого блока питания. Тогда как другие продолжали работать.

Этот вариант крайне маловероятен. На том же ИБП висит еще один сервер и роутер - с ними всё в порядке, работают без остановки.

1. А мониторинг с самого ИБП снимаете?
2. Если ИБП с несколькими банками, то не исключен вариант, что у вас девайсы к разным банкам подключены, и одна из них сдохшая. Например у ИБП в 3 часа ночи запланирован self-test, вот он его запускает, банка мертвая, сервак уходит в даун, self-test закончился, питание вернулось.

Прибейте всякие кроны и другие таймеры и посмотрите ребутнется или нет. Я про то что надо софт проблему исключить. Если это окажется софт проблемой, то выявлять методом половинчатого деления, на тему какая падла инициирует это. С учетом того, что вас не напрягает перевести системное время, то можно относительно быстро найти виновника.

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

Согласен. Но продолжу утверждать что это проблема не линуксовая,а железа,точнее его встроенного ПО (BIOS)

2ТС А это тоже годное предположение, в бивисах встречается отключение по времени.

Складывается ощущение что уже нет их (дисков) когда система выключается.

Хоть и не припоминаю случаев ребута из-за отъехавших дисков, а с мертвыми дисками сталкивался больше одного раза, но это тоже мысль не лишенная определенного смысла. 2ТС Проверить это можно относительно легко, запустите простой скрипт который будет ежесекундно выхлоп date писать в какой-нибудь файл, а потом после очередного ребута сравните время ребута и последней записи в этом файле.

Смотрел какие службы начинают работать в этот момент? Может какая-то джоба на битый сектор натыкается?

Согласно логам - ничего специфического в этот момент работать не начинает.