./debian/rsyslog.dmesg.upstart was shipped by rsyslog package in Trusty and/or other releases.
It was:
start on runlevel [2345]
task
script
savelog -q -p -c 5 /var/log/dmesg
dmesg -s 524288 > /var/log/dmesg
chgrp adm /var/log/dmesg
end script
Thus if such functionality is desired to be preserved, imho rsyslog should be shipping a similar configuration or unit. Note that journald pushes all entries to rsyslog, thus i would have thought it could have generated /var/log/dmesg using normal rsyslog logging configuration facilities.
I'm not sure how to configure rsyslog correctly to retain these. But I can write an equivalent systemd unit:
however, that is slightly incompatible format due to the extra `kernel:` stanza after the timestamp
[1195009.811669] kernel: aufs au_plink_put:436:umount[15188]: pseudo-link is not flushed
--boot 0 -> means to show output from current boot only
--dmesg -> means to show dmesg logs only
--output short-monotonic -> means to prefix things with regular [monotonic] time in dmesg like format
--quiet -> disables the headers with when the logs/boot started finished
--no-pager -> dumps to stdout, instead of less
--no-hostname -> supresses the hostname entry which is injected between time and kernel: normally
E.g. on my system journalctl command above recovers things from 0.000000 time microcode updated, instead of from very late messages.
Imho journalctl should suppress the `kernel:` as that should be implied by --dmesg flag.
Depending on how much things happen during boot, i'm not sure if dmesg should be used, or journalctl to retrieve the boot log.
./debian/ rsyslog. dmesg.upstart was shipped by rsyslog package in Trusty and/or other releases.
It was:
start on runlevel [2345]
task
script
savelog -q -p -c 5 /var/log/dmesg
dmesg -s 524288 > /var/log/dmesg
chgrp adm /var/log/dmesg
end script
Thus if such functionality is desired to be preserved, imho rsyslog should be shipping a similar configuration or unit. Note that journald pushes all entries to rsyslog, thus i would have thought it could have generated /var/log/dmesg using normal rsyslog logging configuration facilities.
I'm not sure how to configure rsyslog correctly to retain these. But I can write an equivalent systemd unit:
$ systemctl cat dmesg system/ dmesg.service
# /etc/systemd/
[Unit]
Description=Save kernel messages
[Service] /usr/bin/ savelog -q -p -c 5 /var/log/dmesg /bin/chgrp adm /var/log/dmesg
Type=idle
ExecStartPre=
ExecStart=/bin/sh -c '/bin/dmesg -s 524288 > /var/log/dmesg'
ExecStartPost=
[Install] multi-user. target
WantedBy=
The dmesg command can be approximated with the following journalctl command, which may have more data than dmesg ring-buffer:
$ journalctl --boot 0 --dmesg --output short-monotonic --quiet --no-pager --no-hostname
however, that is slightly incompatible format due to the extra `kernel:` stanza after the timestamp
[1195009.811669] kernel: aufs au_plink_ put:436: umount[ 15188]: pseudo-link is not flushed
--boot 0 -> means to show output from current boot only
--dmesg -> means to show dmesg logs only
--output short-monotonic -> means to prefix things with regular [monotonic] time in dmesg like format
--quiet -> disables the headers with when the logs/boot started finished
--no-pager -> dumps to stdout, instead of less
--no-hostname -> supresses the hostname entry which is injected between time and kernel: normally
E.g. on my system journalctl command above recovers things from 0.000000 time microcode updated, instead of from very late messages.
Imho journalctl should suppress the `kernel:` as that should be implied by --dmesg flag.
Depending on how much things happen during boot, i'm not sure if dmesg should be used, or journalctl to retrieve the boot log.