Есть вопрос по systemd / journald

dmesg > file

cat /proc/kmsg > file

А зачем?

Так оно же ring buffer. А если система работает несколько недель, то этого лога там не будет. К этому и вопрос

Делаете юнит с первой командой, который цепляете к какому-нибудь таргету из второй команды:

journalctl -k -b >/var/log/kernel-boot.log
systemctl list-units -t target

Так ведь и так все храниться. Сколько недель нужно?
Вот мои логи, всего 288 загрузок, начиная с 18 августа.

$ journalctl --list-boots | head --lines=1
-288 dd9611d73e274fecba62436911df4133 Чт 2016-08-18 15:44:53 +03—Чт 2016-08-18 17:26:03 +03

Вот 137 загрузок назад..

$ journalctl --boot=-137 --dmesg | head --lines=5
-- Logs begin at Чт 2016-08-18 15:44:53 +03, end at Пн 2016-11-14 20:02:07 +03. --
окт 02 15:26:19 localhost kernel: Initializing cgroup subsys cpuset
окт 02 15:26:19 localhost kernel: Initializing cgroup subsys cpu
окт 02 15:26:19 localhost kernel: Initializing cgroup subsys cpuacct
окт 02 15:26:19 localhost kernel: Linux version 4.4.23-1-lts (builduser@andyrtr) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP Fri Sep 30 13:41:31 CEST 2016

Для сравнения вывод dmesg

dmesg | head --lines=4
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.31-1-lts (builduser@andyrtr) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP Thu Nov 10 18:01:16 CET 2016

Дык вопрост то «сразу после загрузки». Если вообще, то это задача системного логгера. То, что в systemd он кривой обходится установкой какого-нибудь rsyslog.

То, что в systemd он кривой

Что значит «кривой»?

Ну у меня до применения напильника под нагрузкой journald хорошо кушал CPU и терял сообщения. Из-за этого была куча неудобств. Пришлось запилить хитрый костыль чтобы основным логгером стал обычный syslog, ну и отдача сообщений по сети + лимитирование сообщений/в секунду отдаваемых journald в зависимости от нагрузки. логи в journald пришлось отключить, так как оно умудрялось зажрать слишком дофига памяти (RAM), оставили только минимальный набор чтобы systemctl status был информативным. Короче, journald не универсальный инструмент, прикидывающийся таковым. Заточен на сферический сервер в вакууме и задачи какого-то редхатовского манагера. Заменой нормального логгера не является и врядли станет, так как цели совсем разные. journald - аналог виндовой системы событий, а не логгер. Для локалхоста подходит, особенно если логи не являются инутруменом работы, а так, на всякий крйне редкий случай. Но это к топику не имеет отношения, это я так, выразил своё субъективное мнение.

Есть и другая точка зрения, заключающаяся в том, что journald вполне пригоден решения 95+% задач и делает свою работу достаточно качественно, а случаи подобные вашему можно рассматривать как исключения и применять иные инструменты.

Не решает он никаких задач. Постановка задачи journald такая - обычному юзеру логи не нужны, и не нужен оверхед с ними связанный. Но иногда они полезны при отладке проблем, так что пусть будут. То есть его первая задача - не выпячиваться. То есть его круг задач ограничен маленьким системами, типа небольших некритичных серверов и десктопов (если таковые есть с т.з. красношляпых). Он напоминает logcat в андроид и эту шуку из busybox, как её там. Ну и соответственно оно конфигурируется минимально и не защищен никак от повышенных нагрузок. То есть с т.з. простого юзера это конечно улучшение, но ему на самом деле всё равно, так как в логи глядит раз в пятилетку. Если нужно с логами делать что-то, то тут уже проблемы, особенно если логов много. Впрочем вряд ли здесь это кому-то интересно, просто скажу что с определенного количества логов оно начинает выжирать память и процессор, так же начинает возникать постоянная задержка записи сообщений, а также их потери. Просто путь лога от системы до диска тернист и сложен. Мне просто кажется, что тащить мобильные технологии на сервера - это не всегда хорошо.

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