Bug #1234
open
src.text.dmesg: some kernel ring buffer lines can be wrongly sorted by time, leading to a muxer error
Added by Philippe Proulx almost 5 years ago.
Updated almost 5 years ago.
Description
The lines of the dmesg command start with a time. The lines are supposed to be in order of time, but some of them can be at the wrong place.
flt.utils.muxer does not like this and complains that event messages are not sorted by their default clock snapshot value.
It is, in fact, a src.text.dmesg bug because a message iterator must emit messages in order of time.
If the input is a file, one solution would be to sort the lines first (if not too large), and then emit the messages in this order.
We could also, in all scenarios, skip the lines with a time that is before the last event message's time and warn accordingly.
- Author changed from 22 to 9
Follow-up:
From Mathieu Desnoyers:
Kernels in the last ~1 year have started doing per-cpu buffering for printk, but do not reorder by time for dmesg.
One possible solution would be to fix this up in the dmesg source plugin: we can create an instance of prio heap per dmesg source component, which can hold at most N events (user configurable with a sane default). The key used to order the events would be their (timestamps, text file line number). The secondary key (lineno) is there to make sure we keep the same order as the input dmesg file if two events have exactly the same timestamp.
If it happens that events go further back in time than the specified limit, we discard them.
The limits in terms of heap size could be specified by the end users in one of two ways (or both):
- size of heap (number of events),
- time delta (how far back do we allow reordering events time-wise).
- Author changed from 9 to 22
- Status changed from New to Feedback
Migrated from internal bug tracker.
Also available in: Atom
PDF