sd_journal_seek_head, sd_journal_seek_tail, sd_journal_seek_monotonic_usec, sd_journal_seek_realtime_usec, sd_journal_seek_cursor — Seek to a position in the journal
|const char *cursor|
sd_journal_seek_head() seeks to the beginning of the journal, i.e. to the
position before the oldest available entry.
sd_journal_seek_tail() may be used to seek to the end of the
journal, i.e. the position after the most recent available entry.
sd_journal_seek_monotonic_usec() seeks to a position with the specified
monotonic timestamp, i.e.
CLOCK_MONOTONIC. Since monotonic time restarts on every
reboot a boot ID needs to be specified as well.
sd_journal_seek_realtime_usec() seeks to a position with the specified
realtime (wallclock) timestamp, i.e.
CLOCK_REALTIME. Note that the realtime clock is
not necessarily monotonic. If a realtime timestamp is ambiguous, it is not defined which position is
sd_journal_seek_cursor() seeks to the position at the specified cursor
string. For details on cursors, see
If no entry matching the specified cursor is found the call will seek to the next closest entry (in terms
of time) instead. To verify whether the newly selected entry actually matches the cursor, use
Note that these calls do not actually make any entry the new current entry, this needs to be done in a separate step with a subsequent sd_journal_next(3) invocation (or a similar call). Only then, entry data may be retrieved via sd_journal_get_data(3) or an entry cursor be retrieved via sd_journal_get_cursor(3). If no entry exists that matches exactly the specified seek address, the next closest is sought to. If sd_journal_next(3) is used, the closest following entry will be sought to, if sd_journal_previous(3) is used the closest preceding entry is sought to.
The functions return 0 on success or a negative errno-style error code.
All functions listed here are thread-agnostic and only a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't operate on it at the very same time.
Functions described here are available as a shared
library, which can be compiled against and linked to with the