Skip to content

Comments

journal: partially revert recent changes#33401

Merged
YHNdnzj merged 3 commits intosystemd:mainfrom
yuwata:journal-revert-source-boottime-timestamp
Jun 24, 2024
Merged

journal: partially revert recent changes#33401
YHNdnzj merged 3 commits intosystemd:mainfrom
yuwata:journal-revert-source-boottime-timestamp

Conversation

@yuwata
Copy link
Member

@yuwata yuwata commented Jun 19, 2024

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.

@yuwata yuwata added the journal label Jun 19, 2024
@github-actions github-actions bot added documentation util-lib please-review PR is ready for (re-)review by a maintainer labels Jun 19, 2024

<varlistentry>
<term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
<term><varname>_SOURCE_MONOTONIC_TIMESTAMP=</varname></term>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm? Why drop this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@poettering
Copy link
Member

The mapping from CLOCK_BOOTTIME -> CLOCK_MONOTONIC may not work

may not work? What precisely do you mean? I mean, it's inaccurate sure, but it's not terrible if we have nothing?

@poettering
Copy link
Member

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.

@yuwata
Copy link
Member Author

yuwata commented Jun 19, 2024

The mapping from CLOCK_BOOTTIME -> CLOCK_MONOTONIC may not work

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, if a kmsg sent before sleep is received by journald after sleep, map_clock_usec() will provide wrong value, as the shift between CLOCK_MONOTONIC and CLOCK_BOOTTIME is changed by the sleep.
So, storing _SOURCE_MONOTONIC_TIMESTAMP with map_clock_usec() does not work, at least with the current way.

@yuwata
Copy link
Member Author

yuwata commented Jun 19, 2024

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.

Yeah, I agree with that anyway introducing _SOURCE_BOOTTIME_TIMESTAMP.

The problem here is _SOURCE_MONOTONIC_TIMESTAMP.

yuwata added 3 commits June 20, 2024 00:10
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.
@yuwata yuwata force-pushed the journal-revert-source-boottime-timestamp branch from bb98d42 to 9545f64 Compare June 19, 2024 15:10
@yuwata yuwata changed the title journal: drop _SOURCE_BOOTTIME_TIMESTAMP field and revert recent changes journal: partially revert recent changes Jun 19, 2024
@yuwata
Copy link
Member Author

yuwata commented Jun 19, 2024

In the revised version, _SOURCE_BOOTTIME_TIMESTAMP is kept. PTAL.

@YHNdnzj YHNdnzj added this to the v257 milestone Jun 19, 2024
@poettering poettering added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed please-review PR is ready for (re-)review by a maintainer labels Jun 24, 2024
Copy link
Member

@YHNdnzj YHNdnzj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, could you open a tracking issue, to make sure this won't be forgotten?

@YHNdnzj YHNdnzj merged commit c53580b into systemd:main Jun 24, 2024
@github-actions github-actions bot removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Jun 24, 2024
@yuwata yuwata deleted the journal-revert-source-boottime-timestamp branch June 24, 2024 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants