mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-23 17:34:00 +03:00
64a7ef8bc0
Triggered by https://bugzilla.redhat.com/show_bug.cgi?id=1609349 This adds two generic paragaphs we include via xinclude. One is the "strict" version, which contains wording saying that we are thread agnostic and what that means. And the other is the "safe" version, for the cases we provide fully safety. Let's then change most man pages to use either of these generic paragraphs. With one exception: man/sd_journal_get_catalog.xml contains both kinds of function, we hence use manual wording.
263 lines
12 KiB
XML
263 lines
12 KiB
XML
<?xml version='1.0'?> <!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
|
<!--
|
|
SPDX-License-Identifier: LGPL-2.1+
|
|
-->
|
|
|
|
<refentry id="sd_journal_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>sd_journal_get_fd</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>sd_journal_get_fd</refentrytitle>
|
|
<manvolnum>3</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>sd_journal_get_fd</refname>
|
|
<refname>sd_journal_get_events</refname>
|
|
<refname>sd_journal_get_timeout</refname>
|
|
<refname>sd_journal_process</refname>
|
|
<refname>sd_journal_wait</refname>
|
|
<refname>sd_journal_reliable_fd</refname>
|
|
<refname>SD_JOURNAL_NOP</refname>
|
|
<refname>SD_JOURNAL_APPEND</refname>
|
|
<refname>SD_JOURNAL_INVALIDATE</refname>
|
|
<refpurpose>Journal change notification
|
|
interface</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<funcsynopsis>
|
|
<funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_get_fd</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_get_events</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_get_timeout</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
<paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_process</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_wait</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
<paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
<funcprototype>
|
|
<funcdef>int <function>sd_journal_reliable_fd</function></funcdef>
|
|
<paramdef>sd_journal *<parameter>j</parameter></paramdef>
|
|
</funcprototype>
|
|
|
|
</funcsynopsis>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><function>sd_journal_get_fd()</function> 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
|
|
<citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
|
|
Use <function>sd_journal_get_events()</function> 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
|
|
<function>sd_journal_reliable_fd()</function>, below.
|
|
<function>sd_journal_get_timeout()</function> will ensure in these
|
|
cases that wake-ups happen frequently enough for changes to be
|
|
noticed, although with a certain latency.</para>
|
|
|
|
<para><function>sd_journal_get_events()</function> will return the
|
|
<function>poll()</function> mask to wait for. This function will
|
|
return a combination of <constant>POLLIN</constant> and
|
|
<constant>POLLOUT</constant> and similar to fill into the
|
|
<literal>.events</literal> field of <varname>struct
|
|
pollfd</varname>.</para>
|
|
|
|
<para><function>sd_journal_get_timeout()</function> will return a
|
|
timeout value for usage in <function>poll()</function>. This
|
|
returns a value in microseconds since the epoch of
|
|
<constant>CLOCK_MONOTONIC</constant> for timing out
|
|
<function>poll()</function> in <varname>timeout_usec</varname>.
|
|
See
|
|
<citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
|
for details about <constant>CLOCK_MONOTONIC</constant>. If there
|
|
is no timeout to wait for, this will fill in <constant>(uint64_t)
|
|
-1</constant> instead. Note that <function>poll()</function> 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:</para>
|
|
|
|
<programlisting>uint64_t t;
|
|
int msec;
|
|
sd_journal_get_timeout(m, &t);
|
|
if (t == (uint64_t) -1)
|
|
msec = -1;
|
|
else {
|
|
struct timespec ts;
|
|
uint64_t n;
|
|
clock_gettime(CLOCK_MONOTONIC, &ts);
|
|
n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
|
|
msec = t > n ? (int) ((t - n + 999) / 1000) : 0;
|
|
}</programlisting>
|
|
|
|
<para>The code above does not do any error checking for brevity's
|
|
sake. The calculated <varname>msec</varname> integer can be passed
|
|
directly as <function>poll()</function>'s timeout
|
|
parameter.</para>
|
|
|
|
<para>After each <function>poll()</function> wake-up
|
|
<function>sd_journal_process()</function> 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).</para>
|
|
|
|
<para>A synchronous alternative for using
|
|
<function>sd_journal_get_fd()</function>,
|
|
<function>sd_journal_get_events()</function>,
|
|
<function>sd_journal_get_timeout()</function> and
|
|
<function>sd_journal_process()</function> is
|
|
<function>sd_journal_wait()</function>. It will synchronously wait
|
|
until the journal gets changed. The maximum time this call sleeps
|
|
may be controlled with the <parameter>timeout_usec</parameter>
|
|
parameter. Pass <constant>(uint64_t) -1</constant> to wait
|
|
indefinitely. Internally this call simply combines
|
|
<function>sd_journal_get_fd()</function>,
|
|
<function>sd_journal_get_events()</function>,
|
|
<function>sd_journal_get_timeout()</function>,
|
|
<function>poll()</function> and
|
|
<function>sd_journal_process()</function> into one.</para>
|
|
|
|
<para><function>sd_journal_reliable_fd()</function> may be used to
|
|
check whether the wakeup events from the file descriptor returned
|
|
by <function>sd_journal_get_fd()</function> 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 <function>sd_journal_get_timeout()</function> on these
|
|
file systems will ask for timeouts explicitly anyway.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Return Value</title>
|
|
|
|
<para><function>sd_journal_get_fd()</function> returns a valid
|
|
file descriptor on success or a negative errno-style error
|
|
code.</para>
|
|
|
|
<para><function>sd_journal_get_events()</function> returns a
|
|
combination of <constant>POLLIN</constant>,
|
|
<constant>POLLOUT</constant> and suchlike on success or a negative
|
|
errno-style error code.</para>
|
|
|
|
<para><function>sd_journal_reliable_fd()</function> returns a
|
|
positive integer if the file descriptor returned by
|
|
<function>sd_journal_get_fd()</function> will generate wake-ups
|
|
immediately for all journal changes. Returns 0 if there might be a
|
|
latency involved.</para>
|
|
|
|
<para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> return a negative
|
|
errno-style error code, or one of <constant>SD_JOURNAL_NOP</constant>, <constant>SD_JOURNAL_APPEND</constant> or
|
|
<constant>SD_JOURNAL_INVALIDATE</constant> on success:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>If <constant>SD_JOURNAL_NOP</constant> is returned, the journal did not change since the last
|
|
invocation.</para></listitem>
|
|
|
|
<listitem><para>If <constant>SD_JOURNAL_APPEND</constant> is returned, new entries have been appended to the end
|
|
of the journal. In this case it is sufficient to simply continue reading at the previous end location of the
|
|
journal, to read the newly added entries.</para></listitem>
|
|
|
|
<listitem><para>If <constant>SD_JOURNAL_INVALIDATE</constant>, journal files were added to or removed from the
|
|
set of journal files watched (e.g. due to rotation or vacuuming), and thus entries might have appeared or
|
|
disappeared at arbitrary places in the log stream, possibly before or after the previous end of the log
|
|
stream. If <constant>SD_JOURNAL_INVALIDATE</constant> is returned, live-view UIs that want to reflect on screen
|
|
the precise state of the log data on disk should probably refresh their entire display (relative to the cursor of
|
|
the log entry on the top of the screen). Programs only interested in a strictly sequential stream of log data may
|
|
treat <constant>SD_JOURNAL_INVALIDATE</constant> the same way as <constant>SD_JOURNAL_APPEND</constant>, thus
|
|
ignoring any changes to the log view earlier than the old end of the log stream.</para></listitem>
|
|
</itemizedlist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Signal safety</title>
|
|
|
|
<para>In general, <function>sd_journal_get_fd()</function>, <function>sd_journal_get_events()</function>, and
|
|
<function>sd_journal_get_timeout()</function> are <emphasis>not</emphasis> "async signal safe" in the meaning of
|
|
<citerefentry
|
|
project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
|
Nevertheless, only the first call to any of those three functions performs unsafe operations, so subsequent calls
|
|
<emphasis>are</emphasis> safe.</para>
|
|
|
|
<para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> are not
|
|
safe. <function>sd_journal_reliable_fd()</function> is safe.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Notes</title>
|
|
|
|
<xi:include href="threads-aware.xml" xpointer="strict"/>
|
|
|
|
<xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<para>Iterating through the journal, in a live view tracking all
|
|
changes:</para>
|
|
|
|
<programlisting><xi:include href="journal-iterate-wait.c" parse="text" /></programlisting>
|
|
|
|
<para>Waiting with <function>poll()</function> (this
|
|
example lacks all error checking for the sake of
|
|
simplicity):</para>
|
|
|
|
<programlisting><xi:include href="journal-iterate-poll.c" parse="text" /></programlisting>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|