[systemd-devel] Journald : from initialramfs to real root
Mantas Mikulėnas
grawity at gmail.com
Wed Feb 26 19:42:32 UTC 2025
On Wed, Feb 26, 2025, 21:29 Thomas HUMMEL <thomas.hummel at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250226/07ef3d11/attachment.htm>
More information about the systemd-devel
mailing list