summaryrefslogtreecommitdiff
path: root/man
diff options
context:
space:
mode:
Diffstat (limited to 'man')
-rw-r--r--man/sd_bus_creds_get_pid.xml14
-rw-r--r--man/systemd-resolve.xml19
-rw-r--r--man/systemd-socket-activate.xml (renamed from man/systemd-activate.xml)42
-rw-r--r--man/systemd.exec.xml55
4 files changed, 61 insertions, 69 deletions
diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml
index 3bcda46656..4c05835568 100644
--- a/man/sd_bus_creds_get_pid.xml
+++ b/man/sd_bus_creds_get_pid.xml
@@ -406,15 +406,11 @@
For processes that are not part of a session, returns -ENXIO.
</para>
- <para><function>sd_bus_creds_has_effective_cap()</function> will
- check whether the capability specified by
- <parameter>capability</parameter> was set in the effective
- capabilities mask. A positive return value means that is was
- set, zero means that it was not set, and a negative return
- value indicates an error. See
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- and <varname>Capabilities=</varname> and
- <varname>CapabilityBoundingSet=</varname> settings in
+ <para><function>sd_bus_creds_has_effective_cap()</function> will check whether the capability specified by
+ <parameter>capability</parameter> was set in the effective capabilities mask. A positive return value means that it
+ was set, zero means that it was not set, and a negative return value indicates an error. See <citerefentry
+ project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> and the
+ <varname>AmbientCapabilities=</varname> and <varname>CapabilityBoundingSet=</varname> settings in
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
diff --git a/man/systemd-resolve.xml b/man/systemd-resolve.xml
index 3779698be3..802d9cbbe6 100644
--- a/man/systemd-resolve.xml
+++ b/man/systemd-resolve.xml
@@ -79,6 +79,13 @@
<cmdsynopsis>
<command>systemd-resolve</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
+ <command> --openpgp</command>
+ <arg choice="plain"><replaceable>USER@DOMAIN</replaceable></arg>
+ </cmdsynopsis>
+
+ <cmdsynopsis>
+ <command>systemd-resolve</command>
+ <arg choice="opt" rep="repeat">OPTIONS</arg>
<command> --statistics</command>
</cmdsynopsis>
@@ -114,6 +121,10 @@
is assumed to be a domain name, that is already prefixed with an SRV type, and an SRV lookup is done (no
TXT).</para>
+ <para>The <option>--openpgp</option> switch may be use to query PGP keys stored as the
+ <ulink url="https://tools.ietf.org/html/draft-wouters-dane-openpgp-02">OPENPGPKEY</ulink> resource records.
+ When this option is specified one or more e-mail address must be specified.</para>
+
<para>The <option>--statistics</option> switch may be used to show resolver statistics, including information about
the number of successful and failed DNSSEC validations.</para>
@@ -198,6 +209,14 @@
</varlistentry>
<varlistentry>
+ <term><option>--openpgp</option></term>
+
+ <listitem><para>Enables OPENPGPKEY resource record resolution (see above). Specified e-mail
+ addresses are converted to the corresponding DNS domain name, and any OPENPGPKEY keys are
+ printed.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>--cname=</option><replaceable>BOOL</replaceable></term>
<listitem><para>Takes a boolean parameter. If true (the default), DNS CNAME or DNAME redirections are
diff --git a/man/systemd-activate.xml b/man/systemd-socket-activate.xml
index 995e6eecce..5d7f157c72 100644
--- a/man/systemd-activate.xml
+++ b/man/systemd-socket-activate.xml
@@ -21,11 +21,11 @@
along with systemd; If not, see <http://www.gnu.org/licenses/>.
-->
-<refentry id="systemd-activate"
+<refentry id="systemd-socket-activate"
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
- <title>systemd-activate</title>
+ <title>systemd-socket-activate</title>
<productname>systemd</productname>
<authorgroup>
@@ -39,18 +39,18 @@
</refentryinfo>
<refmeta>
- <refentrytitle>systemd-activate</refentrytitle>
- <manvolnum>8</manvolnum>
+ <refentrytitle>systemd-socket-activate</refentrytitle>
+ <manvolnum>1</manvolnum>
</refmeta>
<refnamediv>
- <refname>systemd-activate</refname>
+ <refname>systemd-socket-activate</refname>
<refpurpose>Test socket activation of daemons</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
- <command>/usr/lib/systemd/systemd-activate</command>
+ <command>systemd-socket-activate</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
<arg choice="plain"><replaceable>daemon</replaceable></arg>
<arg choice="opt" rep="repeat">OPTIONS</arg>
@@ -60,20 +60,20 @@
<refsect1>
<title>Description</title>
- <para><command>systemd-activate</command> may be used to launch a socket-activated service binary from the command
+ <para><command>systemd-socket-activate</command> may be used to launch a socket-activated service binary from the command
line for testing purposes. It may also be used to launch individual instances of the service binary per connection.
</para>
<para>The daemon to launch and its options should be specified
- after options intended for <command>systemd-activate</command>.
+ after options intended for <command>systemd-socket-activate</command>.
</para>
<para>If the <option>--inetd</option> option is given, the socket file descriptor will be used as the standard
input and output of the launched process. Otherwise, standard input and output will be inherited, and sockets will
be passed through file descriptors 3 and higher. Sockets passed through <varname>$LISTEN_FDS</varname> to
- <command>systemd-activate</command> will be passed through to the daemon, in the original positions. Other sockets
+ <command>systemd-socket-activate</command> will be passed through to the daemon, in the original positions. Other sockets
specified with <option>--listen=</option> will use consecutive descriptors. By default,
- <command>systemd-activate</command> listens on a stream socket, use <option>--datagram</option> and
+ <command>systemd-socket-activate</command> listens on a stream socket, use <option>--datagram</option> and
<option>--seqpacket</option> to listen on datagram or sequential packet sockets instead (see below).
</para>
</refsect1>
@@ -131,18 +131,20 @@
launched process. If <replaceable>VAR</replaceable> is
followed by <literal>=</literal>, assume that it is a
variable–value pair. Otherwise, obtain the value from the
- environment of <command>systemd-activate</command> itself.
+ environment of <command>systemd-socket-activate</command> itself.
</para></listitem>
</varlistentry>
<varlistentry>
- <term><option>--fdname=</option><replaceable>NAME</replaceable></term>
-
- <listitem><para>Specify a name for the activation file
- descriptors. This is equivalent to setting
- <varname>FileDescriptorName=</varname> in socket unit files, and
- enables use of
- <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+ <term><option>--fdname=</option><replaceable>NAME</replaceable><optional>:<replaceable>NAME</replaceable>...</optional></term>
+
+ <listitem><para>Specify names for the file descriptors passed. This is equivalent to setting
+ <varname>FileDescriptorName=</varname> in socket unit files, and enables use of
+ <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ Multiple entries may be specifies using separate options or by separating names with colons
+ (<literal>:</literal>) in one option. In case more names are given than descriptors, superflous ones willl be
+ ignored. In case less names are given than descriptors, the remaining file descriptors will be unnamed.
+ </para></listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="help" />
@@ -180,13 +182,13 @@
<example>
<title>Run an echo server on port 2000</title>
- <programlisting>$ /usr/lib/systemd/systemd-activate -l 2000 --inetd -a cat</programlisting>
+ <programlisting>$ systemd-socket-activate -l 2000 --inetd -a cat</programlisting>
</example>
<example>
<title>Run a socket-activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
- <programlisting>$ /usr/lib/systemd/systemd-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting>
+ <programlisting>$ systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting>
</example>
</refsect1>
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index f0f77c5091..008565c14b 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -778,32 +778,21 @@
<varlistentry>
<term><varname>CapabilityBoundingSet=</varname></term>
- <listitem><para>Controls which capabilities to include in the
- capability bounding set for the executed process. See
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details. Takes a whitespace-separated list of capability
- names as read by
- <citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
- e.g. <constant>CAP_SYS_ADMIN</constant>,
- <constant>CAP_DAC_OVERRIDE</constant>,
- <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will
- be included in the bounding set, all others are removed. If
- the list of capabilities is prefixed with
- <literal>~</literal>, all but the listed capabilities will be
- included, the effect of the assignment inverted. Note that
- this option also affects the respective capabilities in the
- effective, permitted and inheritable capability sets, on top
- of what <varname>Capabilities=</varname> does. If this option
- is not used, the capability bounding set is not modified on
- process execution, hence no limits on the capabilities of the
- process are enforced. This option may appear more than once, in
- which case the bounding sets are merged. If the empty string
- is assigned to this option, the bounding set is reset to the
- empty capability set, and all prior settings have no effect.
- If set to <literal>~</literal> (without any further argument),
- the bounding set is reset to the full set of available
- capabilities, also undoing any previous
- settings.</para></listitem>
+ <listitem><para>Controls which capabilities to include in the capability bounding set for the executed
+ process. See <citerefentry
+ project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+ details. Takes a whitespace-separated list of capability names as read by <citerefentry
+ project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+ e.g. <constant>CAP_SYS_ADMIN</constant>, <constant>CAP_DAC_OVERRIDE</constant>,
+ <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be included in the bounding set, all others are
+ removed. If the list of capabilities is prefixed with <literal>~</literal>, all but the listed capabilities
+ will be included, the effect of the assignment inverted. Note that this option also affects the respective
+ capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the
+ capability bounding set is not modified on process execution, hence no limits on the capabilities of the
+ process are enforced. This option may appear more than once, in which case the bounding sets are merged. If the
+ empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior
+ settings have no effect. If set to <literal>~</literal> (without any further argument), the bounding set is
+ reset to the full set of available capabilities, also undoing any previous settings.</para></listitem>
</varlistentry>
<varlistentry>
@@ -854,20 +843,6 @@
</varlistentry>
<varlistentry>
- <term><varname>Capabilities=</varname></term>
- <listitem><para>Controls the
- <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- set for the executed process. Take a capability string
- describing the effective, permitted and inherited capability
- sets as documented in
- <citerefentry project='mankier'><refentrytitle>cap_from_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
- Note that these capability sets are usually influenced (and
- filtered) by the capabilities attached to the executed file.
- Due to that <varname>CapabilityBoundingSet=</varname> is
- probably a much more useful setting.</para></listitem>
- </varlistentry>
-
- <varlistentry>
<term><varname>ReadWriteDirectories=</varname></term>
<term><varname>ReadOnlyDirectories=</varname></term>
<term><varname>InaccessibleDirectories=</varname></term>