<div dir="ltr"><div dir="ltr">On Tue, Dec 1, 2020 at 1:46 PM Paul Menzel <<a href="mailto:pmenzel%2Bsystemd-devel@molgen.mpg.de">pmenzel+systemd-devel@molgen.mpg.de</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
At least to me, some of the entries with timestamps from resuming should <br>
have timestamps from suspending. Is the reason, that “suspend message“ <br>
was only written to the journal after resume?<br></blockquote><div><br></div><div>Probably because the journald process (like all other userspace processes) had already been frozen when those messages were written to dmesg, so it couldn't really receive them.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is there a way to access the Linux kernel timestamp from within the journal?<br></blockquote><div><br></div><div>Yes, as the <font face="monospace">_SOURCE_MONOTONIC_TIMESTAMP </font>field. (It's stored in microseconds, while dmesg shows it in seconds.)</div><div><br></div><div><font face="monospace">journalctl -o json _TRANSPORT=kernel | jq -r '"[\(._SOURCE_MONOTONIC_TIMESTAMP | tonumber / 1000000)] \(.MESSAGE)"'</font></div><div><br></div><div>Note that the kernel uses the monotonic clock for dmesg messages, which does not advance at all while the system is suspended -- so trying to convert it to realtime will often give wrong results (the same problem as in 'dmesg -e') unless you do something smart with combining it with journald's <font face="monospace">__REALTIME_TIMESTAMP</font>.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>