Отладка блокировки - systemd теряет мои логи

С тех пор, как я «обновился» до systemd в Arch Linux, я продолжаю терять журналы, когда происходит неожиданная блокировка. Я столкнулся с той же проблемой потери журнала месяц назад и просто снова решил проблему. Есть и другие независимые подтверждения .

Ситуация:

• Делая некоторые вещи на Java и с сетевыми утилитами, я увидел, что KDE (часы) завис. Вентилятор процессора стал шумным, а жара повышалась. Указатель мыши все еще может быть перемещен, хотя.
• Я попытался SSH с другой машины (не удалось из-за "нет маршрута к хосту")
• Я подождал несколько минут, возможно, сторожевой таймер НМИ мог убить оскорбительную задачу. Нет кости.
• Ctrl+ Alt+ F1тоже не работал даже после SysRq+R
• Поскольку описанные выше шаги не сработали, я решил выпустить REI последовательности SysRq. После Eэтого экран стал черным, но консоли тоже нет. Даже после SysRq+K
• Таким образом, этот сеанс кажется потерянным, единственное, что можно сделать, это собрать отладочную информацию. Глядя на Википедию , я решил нажать SysRq+ d(показать удерживаемые блокировки) среди некоторых других.
• После нажатия SysRq+ Sя подождал секунду, а затем перезагрузился с SysRq+ B.
• После перезагрузки и входа в консоль я не увидел никаких следов сбоя. Последний зарегистрированный вход был от использования Wireshark, но был все еще промежуток в 45 минут.

(Я работал под управлением Linux v3.8-rc5-218-ga56e160 кстати)

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

Поэтому я спросил на IRC-канале #systemd, и оказалось, что journald (демон ведения журнала systemd) вообще не периодически сбрасывает журналы на диск. Это означает, что ваши журналы всегда в опасности в любое время.

Отправка SIGUSR2на journaldпричины журналы должны быть записаны на диск, но если вы сделаете это несколько раз, многие файлы будут созданы. (опция фактически описывается как «ротация бревен»).

В итоге я решил пойти с другим предложением: использовать выделенный демон syslog для сбора журналов ядра. Поскольку был предложен rsyslog (и я уже имел опыт работы с ним), я рассмотрел этот вариант более подробно. Я написал еще несколько подробностей в Arch Wiki об использовании rsyslog.

Идея состоит в том, чтобы запустить rsyslog, собирая только данные из ядра. Поскольку rsyslog читает из /proc/kmsg(что позволяет только один читатель) и journald читает из /dev/kmsg(разрешено несколько читателей), нет никакого способа, которым демоны теряют логи (очень важно для меня!). Сконфигурируйте rsyslog для записи сообщений ядра в файл и убедитесь, что этот файл вращается, чтобы не использовать дисковое пространство.

Это решение не идеально:

• Другие журналы (например, из NetworkManager) теряются. Эту проблему можно решить путем пересылки большего количества журналов из системного журнала в journald (это означает дублирование!)
• Дублирование логов. Сообщения ядра записываются в два файла. Это не проблема, как правило, количество журналов невелико, и вы бы предпочли иметь больше копий журналов, чем ни одного. Вы также можете использовать быстрые инструменты, например, grepдля одного файла журнала или более медленные, но более изящные journalctl.

Существует пункт TODO для более частой очистки журналов, но он все еще недостаточно надежен:

journal: время от времени отправляйте маркерные сообщения и сразу же синхронизируйте их с fdatasync (), чтобы обеспечить ежечасную гарантированную синхронизацию.

Теперь, надеюсь, systemd / journald получит возможность записывать журналы на диск, но пока мы можем комбинировать инструменты для достижения цели.

Есть два обновления:

1. Теперь, надеюсь, systemd / journald получит возможность записывать журналы на диск, но пока мы можем комбинировать инструменты для достижения цели.

Есть вариант --sync:

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

--syncдоступно с v228:

journalctl получил новый переключатель «--sync», который запрашивает демон журнала записать все до сих пор неписанные сообщения журнала на диск и синхронизировать файлы перед возвратом.

2. Оказывается, journald (демон ведения журнала systemd) вообще не периодически сбрасывает журналы на диск. Это означает, что ваши журналы всегда в опасности в любое время.

man journald.conf(5) говорит:

SyncIntervalSec =

Тайм-аут перед синхронизацией файлов журнала на диск. После синхронизации файлы журнала переводятся в состояние OFFLINE. Обратите внимание, что синхронизация безоговорочно выполняется сразу после регистрации сообщения с приоритетом CRIT, ALERT или EMERG. Следовательно, этот параметр применяется только к сообщениям уровней ERR, WARNING, NOTICE, INFO, DEBUG. Время ожидания по умолчанию составляет 5 минут.

SyncIntervalSec=доступно с v199:

journald теперь явно сбрасывает файлы журнала на диск не позднее, чем через 5 минут после каждой записи. Файл также будет помечен как автономный до следующей записи. Это должно повысить надежность в случае аварии. Задержка синхронизации может быть настроена через SyncIntervalSec = в journald.conf.

Смотрите также:

journald: отправка SIGTERM / SIGINT с низким приоритетом

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