dmesg: как читать сообщения ядра и находить ошибки диска и нехватки памяти

Ядро операционной системы ведёт собственный журнал: когда оно находит оборудование, загружает драйвер, замечает ошибку чтения диска или отключение USB-устройства, оно записывает сообщение в кольцевой буфер. Команда dmesg выводит содержимое этого буфера. Слово «кольцевой» важно: буфер имеет фиксированный размер, и когда он заполняется, новые сообщения вытесняют самые старые. Поэтому на давно работающей машине начала загрузки в нём может уже не быть.

Для долгой истории в Linux с systemd используется журнал: команда journalctl -k показывает сообщения ядра из него, а с ключом -b -1 (предыдущая загрузка) и за прошлые загрузки, если журнал сохраняется на диск. Это зависит от настроек системы.

В новых версиях Linux доступ к буферу для обычного пользователя может быть ограничен параметром kernel.dmesg_restrict. Если команда отвечает отказом в доступе, запустите её с sudo. В macOS dmesg тоже есть, но объём сведений там меньше, а основной журнал системы ведётся иначе: для него используется команда log и приложение «Консоль». Содержимое dmesg на macOS проверяйте на своей версии.

Сырой вывод dmesg длинный и содержит метки времени в секундах с момента загрузки. Несколько ключей делают его читаемым. Набор может отличаться в разных версиях util-linux, поэтому справка на вашей системе остаётся главным источником.

• dmesg -T заменяет секунды на календарную дату и время. В справке отмечено, что преобразование может быть неточным, если система уходила в сон, так что используйте его как ориентир.
• dmesg -w следит за буфером в реальном времени, как tail -f, пока вы не нажмёте Ctrl+C. Удобно: запустили, затем воткнули флешку и увидели реакцию ядра.
• dmesg --level=err,warn оставляет только сообщения уровней ошибка и предупреждение.
• dmesg | tail -n 50 показывает последние пятьдесят строк.
• dmesg | grep -i "ключевое слово" отбирает строки по слову, например по названию устройства.
• sudo dmesg -c выводит буфер и очищает его. Применять стоит осознанно, потому что вы теряете историю; перед этим сохраните вывод в файл.

Для длинного вывода подойдёт less, о нём есть отдельная страница, а для слежения за обычными журналами служб tail -f.

Если система работает нестабильно, файлы читаются с ошибками или iostat показывает большие задержки, откройте dmesg и поищите признаки проблем с накопителем. Они обычно выглядят как повторяющиеся сообщения об ошибках ввода-вывода, о сбросе линии связи с диском или о проблемах файловой системы.

Ключевые слова для поиска: error, I/O error, reset, timeout, ata, nvme, EXT4-fs error, XFS, Buffer I/O, blk_update_request. Единичные сообщения при подключении съёмного носителя могут быть безобидными, а повторяющиеся ошибки на системном диске повод немедленно сделать резервную копию.

Порядок действий:

1. Сохраните вывод в файл: dmesg -T > dmesg.txt. Он пригодится для обращения в поддержку.
2. Определите, к какому устройству относятся записи, и сопоставьте его с именем в iostat или lsblk.
3. Проверьте состояние накопителя средствами самодиагностики, например утилитой smartctl, если она установлена.
4. Не запускайте проверку и ремонт файловой системы на смонтированном разделе без понимания последствий.

Эти сообщения не позволяют ставить окончательный диагноз. Ошибки могут исходить и от кабеля, питания, переходника, и поэтому диагностика идёт по цепочке, а не по одной строке.

Когда оперативной памяти и подкачки перестаёт хватать, ядро Linux может завершить один из процессов, чтобы спасти систему. Этот механизм называют OOM killer (out of memory). Пользователь видит это как внезапное исчезновение программы, и часто никаких сообщений в самой программе нет. Следы остаются в буфере ядра.

Что искать: фразы «Out of memory», «oom-killer», «Killed process» с номером и именем процесса. Рядом обычно выводится сводка о состоянии памяти в момент срабатывания. Выполните, например, dmesg -T | grep -i -E "out of memory|killed process".

Дальше сопоставьте с картиной ресурсов. Посмотрите vmstat 1: были ли si и so ненулевыми перед сбоем. Проверьте free и список процессов ps aux с сортировкой по памяти. Часто причиной становится один разросшийся процесс, утечка в программе или слишком много параллельных задач.

Если процесс работал в контейнере или службе с лимитом памяти, сообщение может ссылаться на контрольную группу, а не на всю машину. Тогда нужно смотреть настройки лимита. А на macOS при нехватке памяти система использует свои механизмы и показывает окно с предложением закрыть программы, поэтому аналогичных записей в dmesg ищите осторожно.

dmesg пригодится не только для сбоев. Когда вы подключаете оборудование, ядро описывает, что произошло: определилось ли устройство, какой драйвер подцепился, какое имя устройству назначено, например диск или сетевой интерфейс. Это ответ на вопрос «система вообще видит эту штуку».

Типичные ситуации:

• Флешка не появляется в проводнике. Запустите dmesg -w, подключите её и посмотрите, появились ли сообщения о новом устройстве или об ошибках.
• Сетевой адаптер не поднимается. В выводе ищите имя интерфейса и сообщения о загрузке прошивки или сбое драйвера.
• Wi-Fi теряет связь. Иногда в буфере остаются сообщения о сбросе адаптера.
• Устройство отключается само. Повторяющиеся записи о подключении и отключении говорят о плохом контакте или питании.

Помните, что dmesg лишь показывает слова ядра. Если оно ничего не написало, это тоже информация: возможно, проблема выше по стеку, в настройках или в приложении. Для сетевых вопросов продолжайте диагностику командами из раздела про ip addr и ethtool.

Если сомневаетесь, с чего начать, пройдите несколько шагов.

• Выполните dmesg -T | tail -n 100 и посмотрите свежие записи.
• Отберите ошибки: dmesg --level=err,warn.
• Поищите слова error, fail, reset, timeout, oom, I/O.
• Сохраните вывод в файл вместе с датой и описанием происходившего.
• Сопоставьте с замерами vmstat и iostat за тот же период.

Один набор записей редко даёт ответ, но он сокращает круг причин. И не забывайте: после перезагрузки буфер начинается заново, поэтому важные сведения лучше сохранять сразу, пока они ещё доступны.