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

resolved: various monitor fixes

5 files changed, 149 insertions, 26 deletions

diff --git a/man/org.freedesktop.resolve1.xml b/man/org.freedesktop.resolve1.xml
index d3aedbc13e..54f0a18418 100644
--- a/man/org.freedesktop.resolve1.xml
+++ b/man/org.freedesktop.resolve1.xml
@@ -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>
 
diff --git a/man/resolvectl.xml b/man/resolvectl.xml
index 19fb0780b5..a9cdfe9187 100644
--- a/man/resolvectl.xml
+++ b/man/resolvectl.xml
@@ -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>
 
diff --git a/man/rules/meson.build b/man/rules/meson.build
index 2925dadc1e..4a497d59c4 100644
--- a/man/rules/meson.build
+++ b/man/rules/meson.build
@@ -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', [], ''],
diff --git a/man/sd_event_add_signal.xml b/man/sd_event_add_signal.xml
index b2aaff87c1..3e8536e961 100644
--- a/man/sd_event_add_signal.xml
+++ b/man/sd_event_add_signal.xml
@@ -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>
-
-    <para>By default, the event source is enabled permanently
-    (<constant>SD_EVENT_ON</constant>), but this may be changed with
+    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
     <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>
 
diff --git a/man/sd_event_set_signal_exit.xml b/man/sd_event_set_signal_exit.xml
new file mode 100644
index 0000000000..e5e675beec
--- /dev/null
+++ b/man/sd_event_set_signal_exit.xml
@@ -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>