journal: partially revert recent changes#33401
Conversation
|
|
||
| <varlistentry> | ||
| <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term> | ||
| <term><varname>_SOURCE_MONOTONIC_TIMESTAMP=</varname></term> |
There was a problem hiding this comment.
As we cannot fix the timestamp, the field should not be used by any user application, hence I do not think we should document it.
may not work? What precisely do you mean? I mean, it's inaccurate sure, but it's not terrible if we have nothing? |
|
I mean, I am certainly on board with inserting the fields under the right name with the right data, independently if we actually use them right away, hence I'd really generate _SOURCE_BOOTTIME_TIMESTAMP if that's what the kernel gives us in kmsg, even if we don't actually us it necessarily. |
I mean, if a kmsg sent before sleep is received by journald after sleep, |
Yeah, I agree with that anyway introducing _SOURCE_BOOTTIME_TIMESTAMP. The problem here is _SOURCE_MONOTONIC_TIMESTAMP. |
This partially reverts commit a9357c2. Some kmsg sent before sleep may be received by systemd-journald after sleep. In that case, map_clock_usec() does not provide correct timestamp. So, we cannot provide reliable _SOURCE_MONOTONIC_TIMESTAMP.
…IME_TIMESTAMP field exists" This reverts commit f5bdecb. Some kmsg sent before sleep may be received by systemd-journald after sleep. In that case, map_clock_usec() does not provide correct timestamp. So, _SOURCE_MONOTONIC_TIMESTAMP field is anyway unreliable. Let's not use the field.
The timestamp is broken at least now. We should not advertise it.
bb98d42 to
9545f64
Compare
|
In the revised version, _SOURCE_BOOTTIME_TIMESTAMP is kept. PTAL. |
YHNdnzj
left a comment
There was a problem hiding this comment.
Hmm, could you open a tracking issue, to make sure this won't be forgotten?
The mapping from CLOCK_BOOTTIME -> CLOCK_MONOTONIC may not work, and we cannot provide reliable source timestamp in CLOCK_MONOTONIC.
Let's revert recent changes, and reconsider how to fix the issue later.