Reimplementing printk()

Posted Feb 27, 2019 1:23 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Parent article: Reimplementing printk()

I have a tool that depends on increasing message timestamps (it uses them as a position marker). Would it be possible to add an option to fall back to the previous behavior for timestamps?

Reimplementing printk()

Posted Feb 27, 2019 3:40 UTC (Wed) by smurf (subscriber, #17840) [Link] (11 responses)

What does your tool do with boot messages? Today, the first 20 lines or so always end up with a timestamp of zero.

In any case, if I were you I'd add my own timestamp (time when the message was read from the kernel).

Reimplementing printk()

Posted Feb 27, 2019 7:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

The application itself is designed to be restartable and I'm using the timestamp to find out unsynchronized logs - I'm just checking the last uploaded log timestamp and then proceed to sync everything that is at or after that timestamp.

Multiple entries with the same timestamp are treated just fine (de-duped), the problem is timestamps going backwards.

I guess I'll have to add more complicated logic to detect unsynchronized messages.

Reimplementing printk()

Posted Feb 27, 2019 8:45 UTC (Wed) by jogness (subscriber, #49775) [Link] (4 responses)

You really should be using the sequence number. That is a reliable, monotonically increasing value. (For my proposal as well.) Also, it allows you to identify if messages are missing.

Reimplementing printk()

Posted Feb 27, 2019 9:45 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

I can't read /dev/kmsg, it might not be accessible. dmesg is all I can reliably get :(

Reimplementing printk()

Posted Feb 27, 2019 11:10 UTC (Wed) by jogness (subscriber, #49775) [Link] (2 responses)

Isn't dmesg just using /dev/kmsg? Or are you using "dmesg -S"?

Reimplementing printk()

Posted Feb 28, 2019 20:34 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I get piped dmesg output. I can play with its options but I don't see how I can make it print sequence numbers.

Reimplementing printk()

Posted Mar 6, 2019 10:46 UTC (Wed) by jogness (subscriber, #49775) [Link]

If you can call dmesg, I expect you can read /dev/kmsg as well. Take a look at the output of:

cat /dev/kmsg

The second field is the sequence number. You can read about the format here:

https://www.kernel.org/doc/Documentation/ABI/testing/dev-...

Reimplementing printk()

Posted Feb 27, 2019 16:44 UTC (Wed) by vadim (subscriber, #35271) [Link] (4 responses)

Why not take advantage of that journald already has the metadata needed to uniquely identify a line?

Reimplementing printk()

Posted Feb 27, 2019 21:00 UTC (Wed) by claytonc (guest, #98599) [Link]

Maybe they are on a distro without systemd?

Reimplementing printk()

Posted Feb 27, 2019 22:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I'm dreaming about the moment I can do this :( For now there's still RHEL6 and Amazon Linux 1 that I need to support.

Reimplementing printk()

Posted Mar 6, 2019 7:39 UTC (Wed) by gravious (guest, #7662) [Link]

The older distros you care about won't have this new printk() stuff backported, surely?

Reimplementing printk()

Posted Mar 6, 2019 13:10 UTC (Wed) by jdel (guest, #130810) [Link]

printk goes straight out serial console ports. journald just taps into a copy of the console data to log it locally.