Bug 1253649 - Regression: journalctl -f broken with initially empty filter result
Regression: journalctl -f broken with initially empty filter result
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Synacek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-08-14 07:27 EDT by Marius Vollmer
Modified: 2015-09-11 02:42 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-11 02:42:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marius Vollmer 2015-08-14 07:27:40 EDT
Description of problem:

journalctl --follow will exit immediately if there are initially no matching entries.  Instead, it should block until a matching entry is appended to the journal.

Example: If you have a new service unit that has never been started, the following will not give the expected result:

 term1# journalctl -f -u new-service
 -- No entries --

 term2# systemctl start new-service

I would expect journalctl in term1 to block and then show the entries produced by new-service.unit when it is eventually started in term2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. journalctl -f -u nonexisting.service; echo Status $?

Actual results:
-- No entries --
Status 0

Expected results:
<no output and journalctl blocks forever>

Additional info:
This is a regression.
Comment 1 Stef Walter 2015-08-14 08:14:16 EDT
This breaks Cockpit: https://github.com/cockpit-project/cockpit/issues/2571
Comment 2 Marius Vollmer 2015-08-14 08:37:08 EDT
This is caused by


which causes journalctl to exit early when there no matches, even with --follow.

That patch should probably look like this:

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -2057,6 +2057,10 @@ int main(int argc, char *argv[]) {
                 log_error_errno(r, "Failed to iterate through journal: %m");
                 return EXIT_FAILURE;
+        if (r == 0 && !arg_follow) {
+                printf("-- No entries --\n");
+                goto finish;
+        }
         if (!arg_follow)
Comment 3 Stef Walter 2015-08-14 10:09:08 EDT
This regression is in systemd-219-21

systemd-219-20 isn't affected.
Comment 4 Stef Walter 2015-08-14 10:16:21 EDT
The commit containing the regression:

commit 02ab86c732576a71179ce12e97d44c289833236d
Author: Lennart Poettering <lennart@poettering.net>
Date:   Fri Jul 24 02:10:32 2015 +0200

    journalctl: properly detect empty journal files
    When we encounter a journal file with exactly zero entries, print a nice
    message and exit, and don't print a weird error message.
Comment 5 Stef Walter 2015-08-14 10:54:39 EDT
The fix posted by Marius above still has the symptom of printing strange messages like: Failed to get realtime timestamp: Cannot assign requested address

Posted a patch upstream which accounts for that: https://github.com/systemd/systemd/pull/958
Comment 6 Stef Walter 2015-08-17 05:24:06 EDT
Fix merged upstream: https://github.com/systemd/systemd/pull/958
Comment 7 Stef Walter 2015-08-17 09:21:01 EDT
Cockpit has temporarily disabled testing the journal in its test suite for this regressed systemd version: 219-21

However Cockpit is still broken by this bug.
Comment 9 Jan Synacek 2015-09-11 02:42:43 EDT
Fixed by https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22

Note You need to log in before you can comment on or make changes to this bug.