<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - journalctl skips first entry after reboot in certain scenario"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63672#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - journalctl skips first entry after reboot in certain scenario"
href="https://bugs.freedesktop.org/show_bug.cgi?id=63672">bug 63672</a>
from <span class="vcard"><a class="email" href="mailto:marius.vollmer@redhat.com" title="Marius Vollmer <marius.vollmer@redhat.com>"> <span class="fn">Marius Vollmer</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=63672#c2">comment #2</a>)
<span class="quote">> Hmm, so, yeah, you found the issue I think, this is indeed broken the way
> you describe. That said, it was actually supposed to be a good thing to
> cache the last positions in all files, to make simple iteration faster.</span >
You mean, in the case where multiple files overlap in time? I didn't think of
that. Isn't my fix broken for that case? Is that actually supported?
(E.g, when iterating, you get entry 1 from file A, then entries 2 and 3 from
file B, then entry 2 from file A, etc. I think with my fix we would go back to
entry 1 from file A after entries 2 and 3 from file B.)
My first idea was to reset current_offset when a file is exhausted (when
next_beyond_location returns 0 in real_journal_next), but that would break the
'guarantee' that you are still on the same position after sd_journal_next has
returned 0, and can get a cursor for that position, for example. Is there such
a guarantee, actually? If not, that should be documented. If there is such a
guarantee, we can do the resetting of exhausted files only if they are not the
current_file, at the end of real_journal_next (I think).
In any case, current_offset should not be reset to 0 when a file is exhausted,
but to a value that indicates that we are one step beyond the beginning _or_
end, as appropriate.
<span class="quote">> Anyway, I'll commit your fix for now, given that O(log(n)) isn't so much
> worse than O(1), and I want to get a new release out, but I will leave this
> bug open, to look into this, add a comment about this and add a TODO item,
> so I really won't forget...</span >
Please consider whether this breaks the overlapping files scenario... I'll try
to make another patch as outlined above.
<span class="quote">> BTW, I greatly appreciate the patches from you! It's awesome getting bug
> reports plus the right patches all the time. That's awesome! Thanks a ton!</span >
My pleasure! It's fun to hack on some real algorithms and data structures for
a change. :)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>