Fix journalctl --follow with non-matching filter
#257
Commits on Aug 5, 2024
-
mount-util: add umount_and_free() helper
(cherry picked from commit a789f72) Related: RHEL-30567
-
journalctl: use DEFINE_MAIN_FUNCTION() macro
(cherry picked from commit 9556e79) Related: RHEL-30567
-
journalctl: fix output when --lines is used with --grep
Previously, we skip the entries before arg_lines unconditionally, which doesn't behave correctly when used with --grep. After this commit, when a pattern is specified, we don't skip the entries early, but rely on the count of the lines shown to tell us when to stop. To achieve that we would have to search backwards instead. Fixes #25147 (cherry picked from commit db46919) Related: RHEL-30567
-
journalctl: fix output when --until is used with --lines
Before this commit, when --lines is specified, we jump to the tail and search afterwards from there, thus breaking --until if used together. After this commit: If both --until and any of --reverse and --lines is specified, things get a little tricky. We seek to the place of --until first. If only --reverse or --reverse and --lines is specified, we search backwards and let the output counter handle --lines for us. If only --lines is used, we just jump backwards arg_lines and search afterwards from there. (cherry picked from commit 81fb537) Related: RHEL-30567
-
journalctl: fix output when --since is used with --lines
Before this commit, if --since is used with --lines=N, we seek to the place of --since and search afterwards there, resulting in outputing the first N lines. After this commit, we only do the above if --since is used without --reverse and --lines. Otherwise we seek to the tail first and check if the entry is within the range of --since later. (cherry picked from commit f582695) Related: RHEL-30567
-
journalctl: fix when --since, --until and --lines are used altogether
This is a follow-up for #26669 (81fb537). After the mentioned commit, we stopped checking if the entry is within the range of --until if --lines is used. However, when --since, --until and --lines=N are used altogether, and the number of lines between --since and --until is smaller than N, we would seek to --since later (f582695). This breaks the assumption that if --lines is set, the boundary is never exceeded because the counter of outputs gets us covered. (cherry picked from commit 5d2ab01) Related: RHEL-30567
-
-
-
test: check if we can use --merge with --follow
Provides coverage for #24565. (cherry picked from commit c11c50a) Related: RHEL-30567
-
journalctl: always initialize global variables
That's not necessary, as they are initialized with zero, but for safety and readability. (cherry picked from commit 4f0165f) Related: RHEL-30567
-
journalctl: use correct variable to check if --since is specified
(cherry picked from commit 20e933a) Related: RHEL-30567
-
-
journalctl: split out action_list_fields()
No functional change, just refactoring. (cherry picked from commit 2ce9a07) Related: RHEL-30567
-
journalctl: split out update_cursor()
No functional change, just refactoring. (cherry picked from commit 8c12d35) Related: RHEL-30567
-
No functional changes, just refactoring. (cherry picked from commit e4c4a9d) Related: RHEL-30567
-
journalctl: replace ppoll() loop with sd_event_loop()
No functional change, just refactoring. (cherry picked from commit 713342d) Related: RHEL-30567
-
journalctl: also update cursor with --follow
Fixes #26746. (cherry picked from commit 24d633e) Related: RHEL-30567
-
-
journalctl: fix --follow with non-matching filter
When there is no matching entry stored in journal, then initial call of `sd_journal_previous()` following `sd_journal_seek_tail()` returns zero, and does not move the read pointer. In the main loop, on every journal event, we call `sd_journal_next()`, even though the current location is tail, and it takes no effect. In such a case, we need to call `sd_journal_previous()` instead of `sd_journal_next()`. (cherry picked from commit 80ec3db) Resolves: RHEL-30567
-
-
journalctl: do not add io event source for stdout if it is a file
Fixes a bug introduced by 713342d. Fixes #28636. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2228089. (cherry picked from commit f882a98) Related: RHEL-30567
-
journalctl: support --lines=+N for showing the oldest N entries
After f582695, the wrong behavior occurred when --since= and --lines= are both specified is fixed. However, it seems that the old behavior is already being somewhat widely used, and the function itself makes sense, i.e. to allow --lines= to output the first N journal entries. Therefore, let's support prefixing the number for --lines= with '+', and provide such functionality. Related: #28746 (cherry picked from commit 8d6791d) Related: RHEL-30567
-
journalctl: don't skip over messages not matching the cursor
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 (cherry picked from commit 4207a55) Related: RHEL-30567
-
journalctl: make --until work again with --after-cursor and --lines
Fixes a regression introduced by 81fb537. If one of the cursor option is specified, we first seek to the cursor position. So, the current position may be out of the time range specified by --until, and we need to verify the timestamp of the current position. Fixes #31776. Co-authored-by: Reid Wahl <nrwahl@protonmail.com> (cherry picked from commit cb2be36) Related: RHEL-30567
-
test: add test case for issue #31776
(cherry picked from commit bf99542) Related: RHEL-30567
