Сервер с операционной системой Ubuntu Server 16 ушёл в перезагрузку. Да-да, не самая новая ОС. Анализ логов не дал понимания, что-же произошло. Как узнать причину перезагрузки?
Большая часть советов из Интернет не дала нужного результата, но потом, парочка статей подсказала где искать. В Oracle Linux есть сервис kdump, который в директорию /var/crash сохраняет аварийный дамп памяти и dmesg. В Ubuntu Server такой службы нет. Однако, где-то же Oracle Linux берёт dmesg даже после аварийного отключения питания сервера, где-то же эти данные есть...
Про pstore
Мы не первые у кого сервер не смог скинуть в файлы лога информацию об аварийном завершении работы. Ещё в доисторические времена у серверов выходили из строя диски, память, отключалось питание. Специально для нас в Linux была сделана такая штука как pstore — Persistent STORagE file system. Основная идея — сохранять лог ошибок где-то в энергонезависимой памяти. И отдельно от дисков. Для сохранения такой информации могут использоваться разные хранилища: — это ACPI ERST и UEFI.
https://lwn.net/Articles/434821
ERST (Error Record Serialization Table) — это механизм, указанный в спецификации ACPI (Advanced Configuration and Power Interface), который позволяет сохранять и извлекать информацию об аппаратных ошибках в энергонезависимое место (например, во флэш-память). Такой механизм обычно реализован в серверных платформах.
Не обычных старых компьютерах есть только одно место с энергонезависимой памятью — это часы реального времени, но там мало места, логи не сбросишь. Но более новые ПК (и сервера) могут иметь память в UEFI.
Выбор куда писать ошибки (ERST или UEFI) можно настроить при конфигурировании ядра. По умолчанию в Ubuntu Server используется ERST, но это не точно.
Ищем ошибки
В любом случае, если ваш сервер реализует механизм pstore, то хранилище в Debian-подобных системах после загрузки монтируется в /sys/fs/pstore.
При хранении дампов в ERST можно увидеть такую картину:
# ls -al /sys/fs/pstore
total 0
drwxr-x--- 2 root root 0 Jul 28 11:35 .
drwxr-xr-x 9 root root 0 Jul 28 11:35 ..
-r--r--r-- 1 root root 17711 Jul 28 11:35 dmesg-erst-6990001317951307777
-r--r--r-- 1 root root 17755 Jul 28 11:35 dmesg-erst-6990001317951307778
-r--r--r-- 1 root root 17736 Jul 28 11:35 dmesg-erst-6990001317951307779
-r--r--r-- 1 root root 17746 Jul 28 11:35 dmesg-erst-6990001317951307780
При хранении дампов в UEFI картина немного другая:
# ls -al /sys/fs/pstore
total 0
drwxr-x--- 2 root root 0 May 9 09:50 .
drwxr-xr-x 7 root root 0 May 9 09:50 ..
-r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001
-r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001
-r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001
-r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001
Вывод данных может и отличаться, здесь приведены примеры для Oracle Linux. В примере ниже он будет немного другой, для Ubuntu Server 16, но это и не принципиально.
Читаем dmesg
Итак, Ubuntu Server 16 аварийно перезагрузился. В логах ничего нет. Смотрим pstore.
ls -al /sys/fs/pstore
Есть один файл dmesg-erst-0. Дата создания файла говорит нам о том, что именно в это время произошёл сбой, как раз в этот период времени в логах ничего найти не удалось.
Копируем файл себе.
cp /sys/fs/pstore/dmesg-erst-0 /tmp
Теперь можно прочитать файл:
cat /tmp/dmesg-erst-0
Дата выводится в неудобном формате, можно исправить с помощью dmesg:
dmesg -T -F /tmp/dmesg-erst-0
Ориентироваться со временем стало проще. Следует понимать, что дата в dmesg живёт какой-то своей жизнью. Не стал разбираться, просто снизу отмотал до первого сбоя, ближе к времени последней записи:
------------[ cut here ]------------ kernel BUG at /build/linux-hwe-IBxGXO/linux-hwe-4.15.0/include/linux/fs.h:2804! invalid opcode: 0000 [#1] SMP PTI
Кто знает как преобразовать дату к удобоваримому виду — пишите в комментариях.
Ссылки
https://blogs.oracle.com/linux/post/pstore-linux-kernel-persistent-storage-file-system
