On Wed, Feb 26, 2025, 21:29 Thomas HUMMEL <thomas.hum...@pasteur.fr> 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 >
