CentOS: пользователь с отдельным файлом открытого ключа

Очевидно, что если система будет работать несколько дней, я не смогу получить эту информацию. Я правильно понимаю здесь?

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

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

dmesg > /var/run/dmesg.boot

Таким образом, моментальный снимок журнала ядра, который был при загрузке, доступен в /var/run/dmesg.boot , даже если с тех пор он прокрутил фактические журналы.

Вам просто нужно написать службу systemd, которая будет делать то же самое. Используйте оболочку для перенаправления

ExecStart=/bin/sh -c "exec dmesg > /run/dmesg.boot"

или что-то вроде redirfd Лорана Берко или fdredir

ExecStart=/usr/local/bin/fdredir --write 1 /run/dmesg.boot dmesg

набора инструментов nosh journalctl -k , если вы хотите сделать снимок журнала systemd, а не только журнала ядра, и сделать его службой Type = oneshot . Либо сделайте его желательным для multi-user.target , либо сделайте его службой DefaultDependencies = no , которая требуется для basic.target .Обратите внимание, что его не нужно заказывать после монтирования локальной файловой системы (например, local-fs.target ). Такой порядок необходим для FreeBSD и OpenBSD, потому что / var / run может быть дисковой файловой системой с ними. В операционных системах systemd / run - это «файловая система API», которая создается при начальной загрузке перед любыми службами.

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

Однако это намного сложнее настроить в мире systemd чем oneshot, который пишет /run/dmesg.boot . Однако это просто в мире семейства daemontools. Это тривиальное упражнение в использовании таких инструментов, как fifo-listen и klog-read или socklog . Передача вывода через демон журнала, который записывает в частный, надежно ограниченный по размеру, автоматически вращающийся каталог журнала, входит в стандартную комплектацию с daemontools / runit / s6 / nosh / perp-managed service.)