New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
journalctl --after-cursor combined with -u misses a log entry #30288
Comments
mrc0mmand
added a commit
to mrc0mmand/systemd
that referenced
this issue
Dec 5, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288
mrc0mmand
added a commit
to mrc0mmand/systemd
that referenced
this issue
Dec 5, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288
mrc0mmand
added a commit
to mrc0mmand/systemd
that referenced
this issue
Dec 5, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288
mrc0mmand
added a commit
to mrc0mmand/systemd
that referenced
this issue
Dec 6, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288
yuwata
pushed a commit
that referenced
this issue
Dec 7, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: #30288
bluca
pushed a commit
to bluca/systemd
that referenced
this issue
Dec 23, 2023
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288 (cherry picked from commit 4207a55)
Werkov
pushed a commit
to Werkov/systemd
that referenced
this issue
Jan 23, 2024
When --after-cursor=/--cursor-file= is used together with a journal filter, we still skipped over the first matching entry even if it wasn't the entry the cursor points at, thus missing one "valid" entry completely. Let's fix this by checking if the entry cursor after seeking matches the user provided cursor, and skip to the next entry only when the cursors match. Resolves: systemd#30288 (cherry picked from commit 4207a55) (cherry picked from commit d68d901)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
250
Used distribution
Yocto Kirkstone
Linux kernel version used
5.15.85-6.2.1-rt55
CPU architectures issue was seen on
aarch64
Component
journalctl
Expected behaviour you didn't see
I am trying to use cursors to detect logs after a specific point in time (in relation with an automated test system).
The basic idea is we do this:
then perform some tests, then later on check for specific logs this way:
When combining --after-cursor with -u in this way, the first message in the log is missing.
With journalctl -c it is working fine (but there is one message from "before" the cursor marker):
Full log:
With filter on a specific unit:
We get exactly the expected messages here.
I expect that when using --after-cursor, we would get this:
Unexpected behaviour you saw
Here is an example without any unit filter, note how the log start with the "____ CURSOR MARKER ____" log as expected, and after it there are 3 messages from our "modem" service:
Now I try to filter this to get only the messages from the modem service:
The cursor marker is not visible (since it is in another unit), but also the fist message from the modem service is now missing. It looks like --after-cursor attempts to get the output from -c and simply skip over the first message, without checking if that message is actually the one pointed by the cursor, or some later message because there were other journalctl options causing the initial message pointed by the cursor to not appear.
Steps to reproduce the problem
Notice that the first message from "some_oter_unit" after the "____ CURSOR MARKER ____" is missing in the second call to journalctl
Additional program output to the terminal or log subsystem illustrating the issue
No response
The text was updated successfully, but these errors were encountered: