On Wed, Feb 26, 2025, 21:29 Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> wrote:
On 2/25/25 7:49 PM, Mantas Mikulėnas wrote:
>> But this seems to go against the fact that intitalramfs journald can
>> show intitialramfs systemd units (which dracut services are) logs, no ?
>
>
> No, why do you think so?
Hello,
Sorry, I had a poor understanding of how this all should fit together.
I've read doc further now.
I thought you said it logged into /run/log to some other place/mechanism
than journald. You obviously meant the volatile /run/log/journal/
journal, right ?
So, indeed it makes sense now.
Still I'm curious about:
1. how one tmpfs can be handed to new root (but this is out of topic)
`mount --bind /run /newroot/run` is one way to do it. Bind mounts let you have the same filesystem mounted at multiple places, effectively.
2. why, assuming rsyslogd uses /proc/kmsg instead of /dev/kmsg
(which you assumed too because of the format and I also assume because I
can see with lsof rsyslogd opened /proc/kmsg + I think its imklog module
can manage console_log_level for instance), I can still dmesg (which
strace shows it opens /dev/kmsg)
Originally dmesg used the syslog() syscall to get the log buffer, but nowadays it reads from /dev/kmsg (which allows it to efficiently implement "dmesg --follow" for example). In both cases it's deliberate that it has a source that isn't consumed by syslogd.
or journalctl -b and see kernel boot
logs which should have been consumed when read through /proc/kmsg.
Reading from /proc/kmsg only "consumes" the buffer for /proc/kmsg, not for other interfaces (i.e. not for /dev/kmsg and not for the syscall).
Ability to handle multiple readers was one of the reasons 3.4 gained support for reading from /dev/kmsg; in fact I think it was added specifically for journald.
(Another difference is that /dev/kmsg can carry metadata fields, much like journal messages; dmesg doesn't show them but journald imports them so that you can do `journalctl /dev/sda1`.)
Or maybe rsyslogd uses SYSLOG_ACTION_READALL of syslog(2) and never
clears the buffer ? or uses both /dev/ and /proc kmsg
Using the syscall would be inefficient as it doesn't provide notifications of new data. I think modern defaults are to use /dev/kmsg (via imkmsg), but your configuration probably uses /proc/kmsg as before.
Thanks again for your help and sorry for the slow catch up I showed in
my understanding.
--
Thomas HUMMEL
HPC Group
Institut PASTEUR
Paris, FRANCE
