С тех пор, как я «обновился» до 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 кстати)
Итак, как я могу убедиться, что мои журналы сохраняются при неправильной перезагрузке из-за блокировки?
systemd
logs
debugging
systemd-journald
Lekensteyn
источник
источник
systemd
или нет? в последнее время я вижу подобные проблемы. Я разместил подробности здесь -> unix.stackexchange.com/questions/414871/…SyncIntervalSec
вариант (среди прочего) в человекеjournald.conf(5)
.man jounrnald.conf(5)
: SyncIntervalSec = ... Обратите внимание, что синхронизация безоговорочно выполняется сразу после регистрации сообщения с приоритетом CRIT, ALERT или EMERG. Следовательно, этот параметр применяется только к сообщениям уровней ERR, WARNING, NOTICE, INFO, DEBUG. Разве это не означает, что если регистрируется критическая ошибка, она должна быть синхронизирована «немедленно» без ожидания интервала? Это означает, что если произойдет критическая ошибка, мы должны увидеть ее вjournald
журналах. Я что-то пропустил?!Ответы:
Поэтому я спросил на IRC-канале #systemd, и оказалось, что journald (демон ведения журнала systemd) вообще не периодически сбрасывает журналы на диск. Это означает, что ваши журналы всегда в опасности в любое время.
Отправка
SIGUSR2
наjournald
причины журналы должны быть записаны на диск, но если вы сделаете это несколько раз, многие файлы будут созданы. (опция фактически описывается как «ротация бревен»).В итоге я решил пойти с другим предложением: использовать выделенный демон syslog для сбора журналов ядра. Поскольку был предложен rsyslog (и я уже имел опыт работы с ним), я рассмотрел этот вариант более подробно. Я написал еще несколько подробностей в Arch Wiki об использовании rsyslog.
Идея состоит в том, чтобы запустить rsyslog, собирая только данные из ядра. Поскольку rsyslog читает из
/proc/kmsg
(что позволяет только один читатель) и journald читает из/dev/kmsg
(разрешено несколько читателей), нет никакого способа, которым демоны теряют логи (очень важно для меня!). Сконфигурируйте rsyslog для записи сообщений ядра в файл и убедитесь, что этот файл вращается, чтобы не использовать дисковое пространство.Это решение не идеально:
grep
для одного файла журнала или более медленные, но более изящныеjournalctl
.Существует пункт TODO для более частой очистки журналов, но он все еще недостаточно надежен:
Теперь, надеюсь, systemd / journald получит возможность записывать журналы на диск, но пока мы можем комбинировать инструменты для достижения цели.
источник
Есть два обновления:
Есть вариант
--sync
:--sync
доступно сv228
:man journald.conf(5)
говорит:SyncIntervalSec=
доступно сv199
:Смотрите также:
journald: отправка SIGTERM / SIGINT с низким приоритетом
источник