NAME¶

sd_journal_get_cutoff_realtime_usec, sd_journal_get_cutoff_monotonic_usec - Read cut-off timestamps from the current journal entry

SYNOPSIS¶

#include <systemd/sd-journal.h>

int sd_journal_get_cutoff_realtime_usec(sd_journal *j, uint64_t *from, uint64_t *to);

int sd_journal_get_cutoff_monotonic_usec(sd_journal *j, sd_id128_t boot_id, uint64_t *from, uint64_t *to);

DESCRIPTION¶

sd_journal_get_cutoff_realtime_usec() retrieves the realtime (wallclock) timestamps of the first and last entries accessible in the journal. It takes three arguments: the journal context object j and two pointers from and to pointing at 64-bit unsigned integers to store the timestamps in. The timestamps are in microseconds since the epoch, i.e. CLOCK_REALTIME. Either one of the two timestamp arguments may be passed as NULL in case the timestamp is not needed, but not both.

sd_journal_get_cutoff_monotonic_usec() retrieves the monotonic timestamps of the first and last entries accessible in the journal. It takes three arguments: the journal context object j, a 128-bit identifier for the boot boot_id, and two pointers to 64-bit unsigned integers to store the timestamps, from and to. The timestamps are in microseconds since boot-up of the specific boot, i.e. CLOCK_MONOTONIC. Since the monotonic clock begins new with every reboot it only defines a well-defined point in time when used together with an identifier identifying the boot, see sd_id128_get_boot(3) for more information. The function will return the timestamps for the boot identified by the passed boot ID. Either one of the two timestamp arguments may be passed as NULL in case the timestamp is not needed, but not both.

RETURN VALUE¶

sd_journal_get_cutoff_realtime_usec() and sd_journal_get_cutoff_monotonic_usec() return 1 on success, 0 if not suitable entries are in the journal or a negative errno-style error code.

Locations pointed to by parameters from and to will be set only if the return value is positive, and obviously, the parameters are non-null.

NOTES¶

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.

These APIs are implemented as a shared library, which can be compiled and linked to with the libsystemd pkg-config(1) file.

SEE ALSO¶

systemd(1), sd-journal(3), sd_journal_open(3), sd_journal_get_realtime_usec(3), sd_id128_get_boot(3), clock_gettime(2)