Hi,

I noticed that /var/log/dmesg.log is empty even though I have local-dmesg enabled. I think the problem is the --console-off parameter in the service definition:
[environment]
cmd_args=!--console-off -T
cmd_log=!/var/log/dmesg.log
Changing this to
[environment]
cmd_args=!-T
cmd_log=!/var/log/dmesg.log
fixes it and dmesg.log gets filled with logs.
Many thanks for this reports. it will be changed by default at the next boot@ -66serv release.
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?
can be a good idea.
I have ditched local-dmesg in favor of the service files provided by stormc. Very nice, thanks for sharing this.
@ stormc: Hi, I think we had the same idea :)

https://github.com/mobinmob/void-66-services/blob/master/usr/share/66/service/klogd
https://github.com/mobinmob/void-66-services/blob/master/usr/share/66/service/syslogd

I based mine on the example scripts of the s6-rc repo.
stormc wrote 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?
I do not think that is a good idea. What happens if someone wants a different syslog implementation (socklogd, rsyslog, syslog-ng, busybox-syslog etc)? Does the -portable- boot@ service grow? Should the services reside inside boot@ ?
Having an oneshot saves the early kernel log and lets the user to enable a logger **if they need it**- it is enough. If more complete kernel logging is required, then klogd is enough, a syslog service too much policy for boot@ IMHO.
@ mobinmob: Me too, I also read the s6 repos :)

Well, I've put both not in boot@ but in my root tree. I do agree that boot@ is probably not the right place... The one-shot dmesg copy is overwritten on each boot and you can as well type dmesg in a rescue shell (until the ring-buffer has not overflown). So, I don't see a benefit from this, is there one?

My proposal was to leverage the module facility to actually offer users a choice of multiple loggers easily being activated: Say you have logger@ 66-log which is the above two services or logger@ metalog which enables metalog... You can surely add more logger@ <whatever_logger> then.

I do think that shipping the above two services in whatever form with 66 may make sense so that one can optionally enable a "syslog solution" just using on-board means, and that's quite nice I think.
stormc wrote The one-shot dmesg copy is overwritten on each boot and you can as well type dmesg in a rescue shell (until the ring-buffer has not overflown). So, I don't see a benefit from this, is there one?
Well... having something on disk can be said to have some advantages. I am not opossed to the idea of proper klog daemon in boot@ however - i think I made that quite clear ;)
stormc wrote My proposal was to leverage the module facility to actually offer users a choice of multiple loggers easily being activated: Say you have logger@ 66-log which is the above two services or logger@ metalog which enables metalog... You can surely add more logger@ <whatever_logger> then.
Why would you use a module service type and not just enable any syslog service? How is using a module easier than using a simple service? :)
With the module you can more easily express dependencies on some generic "logger" which is satisfied by any such logger@ 66-log or logger@ metalog. Granted, could be an overshot for this :)

Hm, if you have, say klogd in boot@ and a syslogd in root then you have to configure syslogd to not also consume klogd's source so to not double-log stuff. That said, I'm also fine with keeping this logging stuff out of boot@ . I do not really have a strong opinion on this...
stormc wroteWith the module you can more easily express dependencies on some generic "logger" which is satisfied by any such logger@ 66-log or logger@ metalog. Granted, could be an overshot for this :)
That is a really good point... Maybe there is a way to do this and not complicate things. It can help with other similar services.
stormc wrote Hm, if you have, say klogd in boot@ and a syslogd in root then you have to configure syslogd to not also consume klogd's source so to not double-log stuff. That said, I'm also fine with keeping this logging stuff out of boot@ . I do not really have a strong opinion on this...
Yes, it will create problems with configuration. I try minimise configuration in my frontend service files, because what should be done in the [environment] section/switches and what should reside in the daemons configuration file(s) is not always clear.
stormc wrote I do think that shipping the above two services in whatever form with 66 may make sense so that one can optionally enable a "syslog solution" just using on-board means, and that's quite nice I think.
Oh, no question about it! They have been very stable in my system.
The main purpose of local-dmesg service is to keep a trace of the kernel log at the boot time and uniquely for the boot. It easier to see what happened on a small file instead of a big one. But i recognize that service can be useless much of the time. Maybe i should simply remove it....

Powered by Obarun