<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2025, 21:29 Thomas HUMMEL <<a href="mailto:thomas.hummel@pasteur.fr">thomas.hummel@pasteur.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/25/25 7:49 PM, Mantas Mikulėnas wrote:<br>
<br>
>> But this seems to go against the fact that intitalramfs journald can<br>
>> show intitialramfs systemd units (which dracut services are) logs, no ?<br>
> <br>
> <br>
> No, why do you think so?<br>
<br>
Hello,<br>
<br>
Sorry, I had a poor understanding of how this all should fit together.<br>
I've read doc further now.<br>
<br>
I thought you said it logged into /run/log to some other place/mechanism <br>
than journald. You obviously meant the volatile /run/log/journal/ <br>
journal, right ?<br>
<br>
So, indeed it makes sense now.<br>
<br>
Still I'm curious about:<br>
<br>
1. how one tmpfs can be handed to new root (but this is out of topic)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">`mount --bind /run /newroot/run` is one way to do it. Bind mounts let you have the same filesystem mounted at multiple places, effectively.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. why, assuming rsyslogd uses /proc/kmsg instead of /dev/kmsg<br>
(which you assumed too because of the format and I also assume because I <br>
can see with lsof rsyslogd opened /proc/kmsg + I think its imklog module <br>
can manage console_log_level for instance), I can still dmesg (which <br>
strace shows it opens /dev/kmsg)</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">or journalctl -b and see kernel boot <br>
logs which should have been consumed when read through /proc/kmsg.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(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`.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or maybe rsyslogd uses SYSLOG_ACTION_READALL of syslog(2) and never <br>
clears the buffer ? or uses both /dev/ and /proc kmsg<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks again for your help and sorry for the slow catch up I showed in <br>
my understanding.<br>
<br>
-- <br>
Thomas HUMMEL<br>
HPC Group<br>
Institut PASTEUR<br>
Paris, FRANCE<br>
</blockquote></div></div></div>