Hm, I have removed local-dmesg from my boot tree since this is just a one-shot snapshot of dmesg and usually log daemons take over the continuous monitoring of /proc/kmsg as more messages may be sent to it than captured with this one-shot at boot time. So it's of limited use IMO. Instead, I'm using this "klogd" service (not using a full-blown logger such as metalog here):
[main]
@ type = longrun
@ version = 0.0.1
@ description = "kernel log daemon"
@ user = ( root )
@ options = ( log )
[start]
@ build = auto
@ execute = (
redirfd -r 0 /proc/kmsg
exec -c
ucspilogd
)
[logger]
@ build = auto
@ backup = 1
@ timestamp = iso
@ destination = /var/log/66/dmesg
This is accompanied by my "syslogd" service listening to /dev/log (as said, no full-blown log daemon here), just for completeness:
[main]
@ type = longrun
@ version = 0.0.1
@ description = "syslog daemon"
@ user = ( root )
@ options = ( log )
@ notify = 3
[start]
@ build = auto
@ execute = (
exec -c
s6-envuidgid nobody
fdmove 1 3
s6-ipcserver -U -1 -- /dev/log
fdmove -c 1 2
ucspilogd
)
Maybe that would make an alternative to choose from via the modules mechanism so that one can either choose, e.g., logger@ metalog or logger@ 66-log, the latter enabling the two services above?