SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #24853 from poettering/resolved-monitor-fixes

Browse Source 
resolved: various monitor fixes
This commit is contained in:
Luca Boccassi
2022-09-30 15:46:13 +01:00
committed by GitHub
parent e69e3830c3 de76643b3f
commit 697f082697
28 changed files with 1103 additions and 214 deletions
Download Patch File Download Diff File Expand all files Collapse all files
man/org.freedesktop.resolve1.xml
-5
View File
@@ -149,7 +149,6 @@ node /org/freedesktop/resolve1 {
readonly s DNSStubListener = '...';
@org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly s ResolvConfMode = '...';
readonly b Monitor = ...;
};
interface org.freedesktop.DBus.Peer { ... };
interface org.freedesktop.DBus.Introspectable { ... };
@@ -251,8 +250,6 @@ node /org/freedesktop/resolve1 {
<variablelist class="dbus-property" generated="True" extra-ref="ResolvConfMode"/>
<variablelist class="dbus-property" generated="True" extra-ref="Monitor"/>
<!--End of Autogenerated section-->
<refsect2>
@@ -637,8 +634,6 @@ node /org/freedesktop/resolve1 {
enabled. Possible values are <literal>yes</literal> (enabled), <literal>no</literal> (disabled),
<literal>udp</literal> (only the UDP listener is enabled), and <literal>tcp</literal> (only the TCP
listener is enabled).</para>
<para>The <varname>Monitor</varname> boolean property reports whether DNS monitoring is enabled.</para>
</refsect2>
</refsect1>
man/resolvectl.xml
+22 -1
View File
@@ -199,6 +199,19 @@
automatically, an explicit reverting is not necessary in that case.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>monitor</command></term>
<listitem><para>Show a continous stream of local client resolution queries and their
responses. Whenever a local query is completed the query's DNS resource lookup key and resource
records are shown. Note that this displays queries issued locally only, and does not immediately
relate to DNS requests submitted to configured DNS servers or the LLMNR or MulticastDNS zones, as
lookups may be answered from the local cache, or might result in multiple DNS transactions (for
example to validate DNSSEC information). If CNAME/CNAME redirection chains are followed, a separate
query will be displayed for each element of the chain. Use <option>--json=</option> to enable JSON
output.</para></listitem>
</varlistentry>
<xi:include href="systemctl.xml" xpointer="log-level" />
</variablelist>
</refsect1>
@@ -379,9 +392,17 @@
query response are shown. Otherwise, this output is suppressed.</para></listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="json" />
<varlistentry>
<term><option>-j</option></term>
<listitem><para>Short for <option>--json=auto</option></para></listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="no-pager" />
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
<xi:include href="standard-options.xml" xpointer="no-pager" />
</variablelist>
</refsect1>
man/rules/meson.build
+4 -1
View File
@@ -555,7 +555,9 @@ manpages = [
''],
['sd_event_add_signal',
'3',
['sd_event_signal_handler_t', 'sd_event_source_get_signal'],
['SD_EVENT_SIGNAL_PROCMASK',
'sd_event_signal_handler_t',
'sd_event_source_get_signal'],
''],
['sd_event_add_time',
'3',
@@ -581,6 +583,7 @@ manpages = [
''],
['sd_event_now', '3', [], ''],
['sd_event_run', '3', ['sd_event_loop'], ''],
['sd_event_set_signal_exit', '3', [], ''],
['sd_event_set_watchdog', '3', ['sd_event_get_watchdog'], ''],
['sd_event_source_get_event', '3', [], ''],
['sd_event_source_get_pending', '3', [], ''],
man/sd_event_add_signal.xml
+21 -18
View File
@@ -19,6 +19,7 @@
<refname>sd_event_add_signal</refname>
<refname>sd_event_source_get_signal</refname>
<refname>sd_event_signal_handler_t</refname>
<refname>SD_EVENT_SIGNAL_PROCMASK</refname>
<refpurpose>Add a UNIX process signal event source to an event
loop</refpurpose>
@@ -30,6 +31,8 @@
<funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
<funcsynopsisinfo><constant>SD_EVENT_SIGNAL_PROCMASK</constant></funcsynopsisinfo>
<funcprototype>
<funcdef>typedef int (*<function>sd_event_signal_handler_t</function>)</funcdef>
<paramdef>sd_event_source *<parameter>s</parameter></paramdef>
@@ -50,30 +53,26 @@
<funcdef>int <function>sd_event_source_get_signal</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><function>sd_event_add_signal()</function> adds a new UNIX
process signal event source to an event loop. The event loop
object is specified in the <parameter>event</parameter> parameter,
and the event source object is returned in the
<parameter>source</parameter> parameter. The
<parameter>signal</parameter> parameter specifies the numeric
signal to be handled (see <citerefentry
<para><function>sd_event_add_signal()</function> adds a new UNIX process signal event source to an event
loop. The event loop object is specified in the <parameter>event</parameter> parameter, and the event
source object is returned in the <parameter>source</parameter> parameter. The
<parameter>signal</parameter> parameter specifies the numeric signal to be handled (see <citerefentry
project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>).</para>
<para>The <parameter>handler</parameter> parameter is a function to call when the signal is received or
<constant>NULL</constant>. The handler function will be passed the <parameter>userdata</parameter>
pointer, which may be chosen freely by the caller. The handler also receives a pointer to a
<structname>signalfd_siginfo</structname> structure containing information about the received signal. See
<citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for further information. The handler may return negative to signal an error (see below), other return
values are ignored. If <parameter>handler</parameter> is <constant>NULL</constant>, a default handler
that calls
<citerefentry
project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
further information. The handler may return negative to signal an error (see below), other return values
are ignored. If <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
<citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
used.</para>
@@ -81,14 +80,18 @@
threads before this function is called (using <citerefentry
project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
<citerefentry
project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>).</para>
project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>). For
convenience, if the special flag <constant>SD_EVENT_SIGNAL_PROCMASK</constant> is ORed into the specified
signal the signal will be automatically masked as necessary, for the calling thread. Note that this only
works reliably if the signal is already masked in all other threads of the process, or if there are no
other threads at the moment of invocation.</para>
<para>By default, the event source is enabled permanently
(<constant>SD_EVENT_ON</constant>), but this may be changed with
<para>By default, the event source is enabled permanently (<constant>SD_EVENT_ON</constant>), but this
may be changed with
<citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
If the handler function returns a negative error code, it will either be disabled after the
invocation, even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the
loop to terminate, see
If the handler function returns a negative error code, it will either be disabled after the invocation,
even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the loop to
terminate, see
<citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para>
man/sd_event_set_signal_exit.xml
+101
View File
@@ -0,0 +1,101 @@
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
<refentry id="sd_event_set_signal_exit" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>sd_event_set_signal_exit</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>sd_event_set_signal_exit</refentrytitle>
<manvolnum>3</manvolnum>
</refmeta>
<refnamediv>
<refname>sd_event_set_signal_exit</refname>
<refpurpose>Automatically leave event loop on <constant>SIGINT</constant> and <constant>SIGTERM</constant></refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>sd_event_set_signal_exit</function></funcdef>
<paramdef>sd_event *<parameter>event</parameter></paramdef>
<paramdef>int b</paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><function>sd_event_set_signal_exit()</function> may be used to ensure the event loop terminates
once a <constant>SIGINT</constant> or <constant>SIGTERM</constant> signal is received. It is a
convencience wrapper around invocations of
<citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
for both signals. The two signals are automatically added to the calling thread's signal mask (if a
program is multi-threaded care should be taken to either invoke this function before the first thread is
started or to manually block the two signals process-wide first).</para>
<para>If the parameter <parameter>b</parameter> is specified as true, the event loop will terminate on
<constant>SIGINT</constant> and <constant>SIGTERM</constant>. If specified as false, it will no
longer. When this functionality is turned off the calling thread's signal mask is restored to match the
state before it was turned on, for the two signals. By default the two signals are not handled by the
event loop, and Linux' default signal handling for them is in effect.</para>
<para>It's customary for UNIX programs to exit on either of these two signals, hence it's typically a
good idea to enable this functionality for the main event loop of a program.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>sd_event_set_signal_exit()</function> returns a positive non-zero value when the setting
was successfully changed. It returns a zero when the specified setting was already in effect. On failure,
it returns a negative errno-style error code.</para>
<refsect2>
<title>Errors</title>
<para>Returned errors may indicate the following problems:</para>
<variablelist>
<varlistentry>
<term><constant>-ECHILD</constant></term>
<listitem><para>The event loop has been created in a different process.</para></listitem>
</varlistentry>
<varlistentry>
<term><constant>-EINVAL</constant></term>
<listitem><para>The passed event loop object was invalid.</para></listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
<xi:include href="libsystemd-pkgconfig.xml" />
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>