sd_journal_get_fd() returns a file descriptor that may be
asynchronously polled in an external event loop and is signaled as
soon as the journal changes, because new entries or files were added,
rotation took place, or files have been deleted, and similar. The
file descriptor is suitable for usage in poll(2). Use
sd_journal_get_events() for an events mask to watch for. The call
takes one argument: the journal context object. Note that not all
file systems are capable of generating the necessary events for
wakeups from this file descriptor for changes to be noticed
immediately. In particular network files systems do not generate
suitable file change events in all cases. Cases like this can be
detected with sd_journal_reliable_fd(), below.
sd_journal_get_timeout() will ensure in these cases that wake-ups
happen frequently enough for changes to be noticed, although with a
sd_journal_get_events() will return the poll() mask to wait for. This
function will return a combination of POLLIN and POLLOUT and similar
to fill into the ".events" field of struct pollfd.
sd_journal_get_timeout() will return a timeout value for usage in
poll(). This returns a value in microseconds since the epoch of
CLOCK_MONOTONIC for timing out poll() in timeout_usec. See
clock_gettime(2) for details about CLOCK_MONOTONIC. If there is no
timeout to wait for, this will fill in (uint64_t) -1 instead. Note
that poll() takes a relative timeout in milliseconds rather than an
absolute timeout in microseconds. To convert the absolute 'us'
timeout into relative 'ms', use code like the following:
if (t == (uint64_t) -1)
msec = -1;
struct timespec ts;
n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
msec = t > n ? (int) ((t - n + 999) / 1000) : 0;
The code above does not do any error checking for brevity's sake. The
calculated msec integer can be passed directly as poll()'s timeout
After each poll() wake-up sd_journal_process() needs to be called to
process events. This call will also indicate what kind of change has
been detected (see below; note that spurious wake-ups are possible).
A synchronous alternative for using sd_journal_get_fd(),
sd_journal_get_events(), sd_journal_get_timeout() and
sd_journal_process() is sd_journal_wait(). It will synchronously wait
until the journal gets changed. The maximum time this call sleeps may
be controlled with the timeout_usec parameter. Pass (uint64_t) -1 to
wait indefinitely. Internally this call simply combines
sd_journal_get_timeout(), poll() and sd_journal_process() into one.
sd_journal_reliable_fd() may be used to check whether the wakeup
events from the file descriptor returned by sd_journal_get_fd() are
known to be immediately triggered. On certain file systems where file
change events from the OS are not available (such as NFS) changes
need to be polled for repeatedly, and hence are detected only with a
certain latency. This call will return a positive value if the
journal changes are detected immediately and zero when they need to
be polled for and hence might be noticed only with a certain latency.
Note that there is usually no need to invoke this function directly
as sd_journal_get_timeout() on these file systems will ask for
timeouts explicitly anyway.
sd_journal_get_fd() returns a valid file descriptor on success or a
negative errno-style error code.
sd_journal_get_events() returns a combination of POLLIN, POLLOUT and
suchlike on success or a negative errno-style error code.
sd_journal_reliable_fd() returns a positive integer if the file
descriptor returned by sd_journal_get_fd() will generate wake-ups
immediately for all journal changes. Returns 0 if there might be a
sd_journal_process() and sd_journal_wait() return one of
SD_JOURNAL_NOP, SD_JOURNAL_APPEND or SD_JOURNAL_INVALIDATE on success
or a negative errno-style error code. If SD_JOURNAL_NOP is returned,
the journal did not change since the last invocation. If
SD_JOURNAL_APPEND is returned, new entries have been appended to the
end of the journal. If SD_JOURNAL_INVALIDATE, journal files were
added or removed (possibly due to rotation). In the latter event,
live-view UIs should probably refresh their entire display, while in
the case of SD_JOURNAL_APPEND, it is sufficient to simply continue
reading at the previous end of the journal.
The sd_journal_get_fd(), sd_journal_get_events(),
sd_journal_reliable_fd(), sd_journal_process() and sd_journal_wait()
interfaces are available as a shared library, which can be compiled
and linked to with the libsystemd pkg-config(1) file.
This page is part of the systemd (systemd system and service manager)
project. Information about the project can be found at
⟨http://www.freedesktop.org/wiki/Software/systemd⟩. If you have a bug
report for this manual page, see
page was obtained from the project's upstream Git repository
⟨https://github.com/systemd/systemd.git⟩ on 2016-07-16. If you dis‐
cover any rendering problems in this HTML version of the page, or you
believe there is a better or more up-to-date source for the page, or
you have corrections or improvements to the information in this
COLOPHON (which is not part of the original manual page), send a mail
systemd 230 SD_JOURNAL_GET_FD(3)