man: slightly update the man page of sd_bus_message_read_basic()

Follow-up for 73a1d7d2433edd1872ec53db3e804009298ebb1d.

.mkosi/mkosi.fedora

@@ -5,7 +5,7 @@
 
 [Distribution]
 Distribution=fedora
-Release=32
+Release=33
 
 [Output]
 Format=gpt_ext4
@@ -58,6 +58,8 @@ BuildPackages=
         p11-kit-devel
         pam-devel
         pcre2-devel
+        perl(IPC::SysV)
+        perl(Time::HiRes)
         pkgconfig
         python3-devel
         python3-lxml

NEWS

@@ -102,16 +102,16 @@ CHANGES WITH 247 in spe:
           but do not handle the "change" action. If a device matching those
           rules is retriggered with the "change" action (as is intended here)
           it would suddenly lose the relevant properties. This always has been
-          a problematic, but as soon as all udev devices are triggered on
-          relevant package upgrades this will become particularly so. It is
-          strongly recommended to fix offending rules so that they can handle a
-          "change" action at any time, and acquire all necessary udev
-          properties even then. Or in other words: the header guard mentioned
-          above (ACTION=="remove",GOTO="xyz_end") is the correct approach to
-          handle this, as it makes sure rules are rerun on "change" correctly,
-          and acccumulate the correct and complete set of udev properties. udev
-          rule definitions that cannot handle "change" events being triggered
-          at arbitrary times should be considered buggy.
+          problematic, but as soon as all udev devices are triggered on relevant
+          package upgrades this will become particularly so. It is strongly
+          recommended to fix offending rules so that they can handle a "change"
+          action at any time, and acquire all necessary udev properties even
+          then. Or in other words: the header guard mentioned above
+          (ACTION=="remove",GOTO="xyz_end") is the correct approach to handle
+          this, as it makes sure rules are rerun on "change" correctly, and
+          accumulate the correct and complete set of udev properties. udev rule
+          definitions that cannot handle "change" events being triggered at
+          arbitrary times should be considered buggy.
 
         * The MountAPIVFS= service file setting now defaults to on if
           RootImage= and RootDirectory= are used, which means that with those

docs/RESOLVED-VPNS.md

@@ -0,0 +1,267 @@
+---
+title: systemd-resolved and VPNs
+category: Networking
+layout: default
+---
+
+# `systemd-resolved.service` and VPNs
+
+`systemd-resolved.service` supports routing lookups for specific domains to specific
+interfaces. This is useful for hooking up VPN software with systemd-resolved
+and making sure the exact right lookups end up on the VPN and on the other
+interfaces.
+
+For a verbose explanation of `systemd-resolved.service`'s domain routing logic,
+see its [man
+page](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html). This
+document is supposed to provide examples to use the concepts for the specific
+purpose of managing VPN DNS configuration.
+
+Let's first define two distinct VPN use-cases:
+
+1. *Corporate* VPNs, i.e. VPNs that open access to a specific set of additional
+   hosts. Only specific domains should be resolved via the VPN's DNS servers,
+   and everything that is not related to the company's domain names should go
+   to regular, non-VPN DNS instead.
+
+2. *Privacy* VPNs, i.e. VPNs that should be used for basically all DNS traffic,
+   once they are up. If this type of VPN is used, any regular, non-VPN DNS
+   servers should not get any traffic anymore.
+
+Then, let's briefly introduce three DNS routing concepts that software managing
+a network interface may configure.
+
+1. Search domains: these are traditional DNS configuration parameters and are
+   used to suffix non-qualified domain names (i.e. single-label ones), to turn
+   them into fully qualified domain names. Traditionally (before
+   `systemd-resolved.service`), search domain names are attached to a system's
+   IP configuration as a whole, in `systemd-resolved.service` they are
+   associated to individual interfaces instead, since they are typically
+   acquired through some network associated concept, such as a DHCP, IPv6RA or
+   PPP lease. Most importantly though: in `systemd-resolved.service` they are
+   not just used to suffix single-label domain names, but also for routing
+   domain name lookups: if a network interface has a search domain `foo.com`
+   configured on it, then any lookups for names ending in `.foo.com` (or for
+   `foo.com` itself) are preferably routed to the DNS servers configured on the
+   same network interface.
+
+2. Routing domains: these are very similar to search domains, but are purely
+   about DNS domain name lookup routing — they are not used for qualifying
+   single-label domain names. When it comes to routing assigning a routing
+   domain to a network interface is identical to assigning a search domain to
+   it.
+
+   Why the need to have both concepts, i.e. search *and* routing domains?
+   Mostly because in many cases the qualifying of single-label names is not
+   desirable (since security-sensitive), but needs to be supported for specific
+   use-cases. Routing domains are a concept `systemd-resolved.service`
+   introduced, while search domains are traditionally available and are part of
+   DHCP/IPv6RA/PPP leases and thus universally supported. In many cases routing
+   domains are probably the more appropriate concept, but not easily available,
+   since not part of DHCP/IPv6RA/PPP.
+
+   Routing domains for `systemd-resolved.service` are usually presented along
+   with search domains in mostly the same way, but prefixed with `~` to
+   differentiate them. i.e. `~foo.com` is a configured routing domain, while
+   `foo.com` would be a configured search domain.
+
+   One routing domain is particular interesting: `~.` — the catch-all routing
+   domain. (The *dot* domain `.` is how DNS denotes the "root" domain, i.e. the
+   parent domain of all domains, but itself.) When used on an interface any DNS
+   traffic is preferably routed to its DNS servers. (A search domain – i.e. `.`
+   instead of `~.` — would have the same effect, but given that it's mostly
+   pointless to suffix an unqualified domain with `.`, we generally declare it
+   as a routing domain, not a search domain).
+
+   Routing domains also have particular relevance when it comes to the reverse
+   lookup DNS domains `.in-addr.arpa` and `.ip6.arpa`. An interface that has
+   these (or sub-domains thereof) defined as routing domains, will be preferably
+   used for doing reverse IP to domain name lookups. e.g. declaring
+   `~168.192.in-addr.arpa` on an interface means that all lookups to find the
+   domain names for IPv4 addresses 192.168.x.y are preferable routed to it.
+
+3. The `default-route` boolean. This is a simple boolean value that may be set
+   on an interface. If true (the default), any DNS lookups for which no
+   matching routing or search domains are defined are routed to interfaces
+   marked like this. If false then the DNS servers on this interface are not
+   considered for routing lookups to except for the ones listed in the
+   search/routing domain list. An interface that has no search/routing domain
+   associated and also has this boolean off is not considered for *any*
+   lookups.
+
+One more thing to mention: in `systemd-resolved.service` if lookups match the
+search/routing domains of multiple interfaces at once, then they are sent to
+all of them in parallel, and the first positive reply used. If all lookups fail
+the last negative reply is used. This means the DNS zones on the relevant
+interfaces are "merged": domains existing on one but not the other will "just
+work" and vice versa.
+
+And one more note: the domain routing logic implemented is a tiny bit more
+complex that what described above: if there two interfaces have search domains
+that are suffix of each other, and a name is looked up that matches both, the
+interface with the longer match will win and get the lookup routed to is DNS
+servers. Only if the match has the same length, then both will be used in
+parallel. Example: one interface has `~foo.example.com` as routing domain, and
+another one `example.com` has search domain. A lookup for
+`waldo.foo.example.com` is the exclusively routed to the first interface's DNS
+server, since it matches by three suffix labels instead of just two. The fact
+that the matching length is taken into consideration for the routing decision
+is particularly relevant if you have one interface with the `~.` routing domain
+and another one with `~corp.company.example` — both suffixes match a lookup for
+`foo.corp.company.example`, but the latter interface wins, since the match is
+for four labels, while the other is for zero labels.
+
+# Putting it Together
+
+Let's discuss how the three DNS routing concepts above are best used for a
+reasonably complex scenario consisting of:
+
+1. One VPN interface of the *corporate* kind, maybe called `company0`. It makes
+   available a bunch of servers, all in the domain `corp.company.example`.
+
+2. One VPN interface of the *privacy* kind, maybe called `privacy0`. When it is
+   up all DNS traffic shall preferably routed to its DNS servers.
+
+3. One regular WiFi interface, maybe called `wifi0`. It has a regular DNS
+   server on it.
+
+Here's how to best configure this for `systemd-resolved.service`:
+
+1. `company0` should get a routing domain `~corp.company.example`
+   configured. (A search domain `corp.company.example` would work too, if
+   qualifying of single-label names is desired or the VPN lease information
+   does not provide for the concept of routing domains, but does support search
+   domains.) This interface should also set `default-route` to false, to ensure
+   that really only the DNS lookups for the company's servers are routed there
+   and nothing else. Finally, it might make sense to also configure a routing
+   domain `~2.0.192.in-addr.arpa` on the interface, ensuring that all IPv4
+   addresses from the 192.0.2.x range are preferably resolved via the DNS
+   server on this interface (assuming that that's the IPv4 address range the
+   company uses internally).
+
+2. `privacy0` should get a routing domain `~.` configured. The setting of
+   `default-route` for this interface is then irrelevant. This means: once the
+   interface is up, all DNS traffic is preferably routed there.
+
+3. `wifi0` should not get any special settings, except possibly whatever the
+   local WiFi router considers suitable as search domain, for example
+   `fritz.box`. The default `true` setting for `default-route` is good too.
+
+With this configuration if only `wifi0` is up, all DNS traffic goes to its DNS
+server, since there are no other interfaces with better matching DNS
+configuration. If `privacy0` is then upped, all DNS traffic will exclusively go
+to this interface now — with the exception of names below the `fritz.box`
+domain, which will continue to go directly to `wifi0`, as the search domain
+there says so. Now, if `company0` is also upped, it will receive DNS traffic
+for the company's internal domain and internal IP subnet range, but nothing
+else.  If `privacy0` is then downed again, `wifi0` will get the regular DNS
+traffic again, and `company0` will still get the company's internal domain and
+IP subnet traffic and nothing else. Everything hence works as intended.
+
+# How to Implement this in Your VPN Software
+
+Most likely you want to expose a boolean in some way that declares whether a
+specific VPN is of the *corporate* or the *privacy* kind:
+
+1. If managing a *corporate* VPN, you configure any search domains the user or
+   the VPN contact point provided. And you set `default-route` to false. If you
+   have IP subnet information for the VPN, it might make sense to insert
+   `~….in-addr.arpa` and `~….ip6.arpa` reverse lookup routing domains for it.
+
+2. If managing a *privacy* VPN, you include `~.` in the routing domains, the
+   value for `default-route` is actually irrelevant, but I'd set it to true. No
+   need to configure any reverse lookup routing domains for it.
+
+(If you also manage regular WiFi/Ethernet devices, just configure them as
+traditional, i.e. with any search domains as acquired, do not set `~.` though,
+and do not disable `default-route`.)
+
+# The APIs
+
+Now we determined how we want to configure things, but how do you actually get
+the configuration to `systemd-resolved.service`? There are three relevant
+interfaces:
+
+1. Ideally, you use D-Bus and talk to [`systemd-resolved.service`'s D-Bus
+   API](https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html)
+   directly. Use `SetLinkDomains()` to set the per-interface search and routing
+   domains on the interfaces you manage, and `SetLinkDefaultRoute()` to manage
+   the `default-route` boolean, all on the `org.freedesktop.resolve1.Manager`
+   interface of the `/org/freedesktop/resolve1` object.
+
+2. If that's not in the cards, you may shell out to
+   [`resolvectl`](https://www.freedesktop.org/software/systemd/man/resolvectl.html),
+   which is a thin wrapper around the D-Bus interface mentioned above. Use
+   `resolvectl domain <iface> …` to set the search/routing domains and
+   `resolvectl default-route <iface> …` to set the `default-route` boolean.
+
+   Example use from a shell callout of your VPN software for a *corporate* VPN:
+
+        resolvectl domain corporate0 '~corp-company.example' '~2.0.192.in-addr.arpa'
+        resolvectl default-route corporate0 false
+        resolvectl dns corporate0 192.0.2.1
+
+   Example use from a shell callout of your VPN software for a *privacy* VPN:
+
+        resolvectl domain privacy0 '~.'
+        resolvectl default-route privacy0 true
+        resolvectl dns privacy0 8.8.8.8
+
+3. If you don't want to use any `systemd-resolved` commands, you may use the
+   `resolvconf` wrapper we provide. `resolvectl` is actually a multi-call
+   binary and may be symlinked to `resolvconf`, and when invoked like that
+   behaves in a way that is largely compatible with FreeBSD's and
+   Ubuntu's/Debian's
+   [`resolvconf(8)`](https://manpages.ubuntu.com/manpages/trusty/man8/resolvconf.8.html)
+   tool. When the `-x` switch is specified, the `~.` routing domain is
+   automatically appended to the domain list configured, as appropriate for a
+   *privacy* VPN. Note that the `resolvconf` interface only covers *privacy*
+   VPNs and regular network interfaces (such as WiFi or Ethernet) well. The
+   *corporate* kind of VPN is not well covered, since the interface cannot
+   propagate the `default-route` boolean, nor can be used to configure the
+   `~….in-addr.arpa` or `~.ip6.arpa` routing domains.
+
+# Ordering
+
+When configuring per-interface DNS configuration settings it is wise to
+configure everything *before* actually upping the interface. Once the interface
+is up `systemd-resolved.service` might start using it, and hence it's important
+to have everything configured properly (this is particularly relevant when
+LLMNR or MulticastDNS is enabled, since that works without any explicitly
+configured DNS configuration). It is also wise to configure search/routing
+domains and the `default-route` boolean *before* configuring the DNS servers,
+as the former without the latter has no effect, but the latter without the
+former will result in DNS traffic possibly being generated, in a non-desirable
+way given that the routing information is not set yet.
+
+# Downgrading Search Domains to Routing Domains
+
+Many VPN implementations provide a way how VPN servers can inform VPN clients
+about search domains to use. In some cases it might make sense to install those
+as routing domains instead of search domains. Unqualified domain names usually
+imply a context of locality: the same unqualified name typically is expected to
+resolve to one system in one local network, and to another one in a different
+network.  Search domains thus generally come with security implications: they
+might cause that unqualified domains are resolved in a different (possibly
+remote) context, contradicting user expectations. Thus it might be wise to
+downgrade *search domains* provided by VPN servers to *routing domains*, so
+that local unqualified name resolution remains untouched and strictly maintains
+its local focus — in particular in the aforementioned less trusted *corporate*
+VPN scenario.
+
+To illustrate this further, here's an example for an attack scenario using
+search domains: a user assumes the printer system they daily contact under the
+unqualified name "printer" is the network printer in their basement (with the
+fully qualified domain name "printer.home"). Sometimes the user joins the
+corporate VPN of their employer, which comes with a search domain
+"foocorp.example", so that the user's confidential documents (maybe a job
+application to a competing company) might end up being printed on
+"printer.foocorp.example" instead of "printer.home". If the local VPN software
+had downgraded the VPN's search domain to a routing domain "~foocorp.example",
+this mismapping would not have happened.
+
+When connecting to untrusted WiFi networks it might be wise to go one step
+further even: suppress installation of search/routing domains by the network
+entirely, to ensure that the local DNS information is only used for name
+resolution of qualified names and only when no better DNS configuration is
+available.

man/bootctl.xml

@@ -112,7 +112,7 @@
         These special IDs are primarily useful as a quick way to persistently make the currently booted boot loader
         entry the default choice, or to upgrade the default boot loader entry for the next boot to the default boot
         loader entry for all future boots, but may be used for other operations too.
-        When an emptry string ("") is specified as an ID, then the corresponding EFI variable will be unset.
+        When an empty string ("") is specified as an ID, then the corresponding EFI variable will be unset.
         </para></listitem>
       </varlistentry>
 

man/sd_bus_message_read_basic.xml

@@ -188,9 +188,9 @@
     <title>Return Value</title>
 
     <para>
-      On success, <function>sd_bus_message_read_basic()</function> returns 0 or
-      a positive integer. On failure, it returns a negative errno-style error
-      code.
+      On success, <function>sd_bus_message_read_basic()</function> returns a positive integer.
+      If the end of the currently opened array has been reached, it returns 0.
+      On failure, it returns a negative errno-style error code.
     </para>
 
     <refsect2 id='errors'>

man/systemd-system.conf.xml

@@ -361,8 +361,10 @@
         <listitem><para>Configure the default value for the per-unit <varname>TasksMax=</varname> setting. See
         <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
         for details. This setting applies to all unit types that support resource control settings, with the exception
-        of slice units. Defaults to 15%, which equals 4915 with the kernel's defaults on the host, but might be smaller
-        in OS containers.</para></listitem>
+        of slice units. Defaults to 15% of the sysctl setting <varname>kernel.pid_max=</varname> or root cgroup <varname>pids.max</varname>.
+        Kernel has a default value for <varname>kernel.pid_max=</varname> and an algorithm of counting in case of more than 32 cores.
+        For example with the default <varname>kernel.pid_max=</varname>, <varname>DefaultTasksMax=</varname> defaults to 4915,
+        but might be greater in other systems or smaller in OS containers.</para></listitem>
       </varlistentry>
 
       <varlistentry>

man/systemd.unit.xml

@@ -1734,10 +1734,9 @@
       </varlistentry>
     </variablelist>
 
-    <para>The following specifiers are interpreted in the Install
-    section: %n, %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. For their
-    meaning see the next section.
-    </para>
+    <para>The following specifiers are interpreted in the Install section:
+    %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%.
+    For their meaning see the next section.</para>
   </refsect1>
 
   <refsect1>
@@ -1787,6 +1786,16 @@
             <entry>Unescaped filename</entry>
             <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>. This implements unescaping according to the rules for escaping absolute file system paths discussed above.</entry>
           </row>
+          <row>
+            <entry><literal>%g</literal></entry>
+            <entry>User group</entry>
+            <entry>This is the name of the group running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
+          </row>
+          <row>
+            <entry><literal>%G</literal></entry>
+            <entry>User GID</entry>
+            <entry>This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry>
+          </row>
           <row>
             <entry><literal>%h</literal></entry>
             <entry>User home directory</entry>
@@ -1801,11 +1810,6 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
             <entry>Host name</entry>
             <entry>The hostname of the running system at the point in time the unit configuration is loaded.</entry>
           </row>
-          <row>
-            <entry><literal>%l</literal></entry>
-            <entry>Short host name</entry>
-            <entry>The hostname of the running system at the point in time the unit configuration is loaded, truncated at the first dot to remove any domain component.</entry>
-          </row>
           <row>
             <entry><literal>%i</literal></entry>
             <entry>Instance name</entry>
@@ -1826,13 +1830,17 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
             <entry>Unescaped final component of the prefix</entry>
             <entry>Same as <literal>%j</literal>, but with escaping undone.</entry>
           </row>
+          <row>
+            <entry><literal>%l</literal></entry>
+            <entry>Short host name</entry>
+            <entry>The hostname of the running system at the point in time the unit configuration is loaded, truncated at the first dot to remove any domain component.</entry>
+          </row>
           <row>
             <entry><literal>%L</literal></entry>
             <entry>Log directory root</entry>
             <entry>This is either <filename>/var/log</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to with <filename index="false">/log</filename> appended (for user managers).</entry>
           </row>
           <xi:include href="standard-specifiers.xml" xpointer="m"/>
-          <xi:include href="standard-specifiers.xml" xpointer="o"/>
           <row>
             <entry><literal>%n</literal></entry>
             <entry>Full unit name</entry>
@@ -1843,6 +1851,7 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
             <entry>Full unit name</entry>
             <entry>Same as <literal>%n</literal>, but with the type suffix removed.</entry>
           </row>
+          <xi:include href="standard-specifiers.xml" xpointer="o"/>
           <row>
             <entry><literal>%p</literal></entry>
             <entry>Prefix name</entry>
@@ -1869,16 +1878,6 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
             <entry>This is either <filename>/run/</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
           </row>
           <xi:include href="standard-specifiers.xml" xpointer="T"/>
-          <row>
-            <entry><literal>%g</literal></entry>
-            <entry>User group</entry>
-            <entry>This is the name of the group running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
-          </row>
-          <row>
-            <entry><literal>%G</literal></entry>
-            <entry>User GID</entry>
-            <entry>This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry>
-          </row>
           <row>
             <entry><literal>%u</literal></entry>
             <entry>User name</entry>

man/tmpfiles.d.xml

@@ -639,6 +639,16 @@ w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
               <entry>System or user cache directory</entry>
               <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_CACHE_HOME</varname>, and <filename>/var/cache</filename> otherwise.</entry>
             </row>
+            <row>
+              <entry><literal>%g</literal></entry>
+              <entry>User group</entry>
+              <entry>This is the name of the group running the command. In case of the system instance this resolves to <literal>root</literal>.</entry>
+            </row>
+            <row>
+              <entry><literal>%G</literal></entry>
+              <entry>User GID</entry>
+              <entry>This is the numeric GID of the group running the command. In case of the system instance this resolves to <constant>0</constant>.</entry>
+            </row>
             <row>
               <entry><literal>%h</literal></entry>
               <entry>User home directory</entry>
@@ -664,16 +674,6 @@ w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
               <entry>In <option>--user</option> mode, this is the same <varname>$XDG_RUNTIME_DIR</varname>, and <filename>/run/</filename> otherwise.</entry>
             </row>
             <xi:include href="standard-specifiers.xml" xpointer="T"/>
-            <row>
-              <entry><literal>%g</literal></entry>
-              <entry>User group</entry>
-              <entry>This is the name of the group running the command. In case of the system instance this resolves to <literal>root</literal>.</entry>
-            </row>
-            <row>
-              <entry><literal>%G</literal></entry>
-              <entry>User GID</entry>
-              <entry>This is the numeric GID of the group running the command. In case of the system instance this resolves to <constant>0</constant>.</entry>
-            </row>
             <row>
               <entry><literal>%u</literal></entry>
               <entry>User name</entry>

src/basic/escape.h

@@ -16,7 +16,7 @@
 
 /* Those that can be escaped or double-quoted.
  *
- * Stricly speaking, ! does not need to be escaped, except in interactive
+ * Strictly speaking, ! does not need to be escaped, except in interactive
  * mode, but let's be extra nice to the user and quote ! in case this
  * output is ever used in interactive mode. */
 #define SHELL_NEED_QUOTES SHELL_NEED_ESCAPE GLOB_CHARS "'()<>|&;!"

src/core/mount.c

@@ -1948,6 +1948,15 @@ static int mount_process_proc_self_mountinfo(Manager *m) {
                                 mount_enter_dead(mount, MOUNT_SUCCESS);
                                 break;
 
+                        case MOUNT_MOUNTING_DONE:
+                                /* The mount command may add the corresponding proc mountinfo entry and
+                                 * then remove it because of an internal error. E.g., fuse.sshfs seems
+                                 * to do that when the connection fails. See #17617. To handle such the
+                                 * case, let's once set the state back to mounting. Then, the unit can
+                                 * correctly enter the failed state later in mount_sigchld(). */
+                                mount_set_state(mount, MOUNT_MOUNTING);
+                                break;
+
                         default:
                                 break;
                         }

src/core/unit-printf.c

@@ -177,35 +177,23 @@ int unit_name_printf(const Unit *u, const char* format, char **ret) {
          * This will use the passed string as format string and replace the following specifiers (which should all be
          * safe for inclusion in unit names):
          *
-         * %n: the full id of the unit                 (foo@bar.waldo)
-         * %N: the id of the unit without the suffix   (foo@bar)
-         * %p: the prefix                              (foo)
+         * %n: the full id of the unit                 (foo-aaa@bar.waldo)
+         * %N: the id of the unit without the suffix   (foo-aaa@bar)
+         * %p: the prefix                              (foo-aaa)
          * %i: the instance                            (bar)
-         *
-         * %U: the UID of the running user
-         * %u: the username of the running user
-         *
-         * %m: the machine ID of the running system
-         * %b: the boot ID of the running system
-         * %H: the hostname of the running system
-         * %v: the kernel version
-         * %a: the native userspace architecture
-         * %o: the OS ID according to /etc/os-release
-         * %w: the OS version ID, according to /etc/os-release
-         * %B: the OS build ID, according to /etc/os-release
-         * %W: the OS variant ID, according to /etc/os-release
+         * %j: the last componet of the prefix         (aaa)
          */
 
         const Specifier table[] = {
+                { 'i', specifier_string,              u->instance },
+                { 'j', specifier_last_component,      NULL },
                 { 'n', specifier_string,              u->id },
                 { 'N', specifier_prefix_and_instance, NULL },
                 { 'p', specifier_prefix,              NULL },
-                { 'i', specifier_string,              u->instance },
-                { 'j', specifier_last_component,      NULL },
-
-                COMMON_CREDS_SPECIFIERS,
 
                 COMMON_SYSTEM_SPECIFIERS,
+
+                COMMON_CREDS_SPECIFIERS,
                 {}
         };
 
@@ -226,19 +214,15 @@ int unit_full_printf(const Unit *u, const char *format, char **ret) {
          * %r: where units in this slice are placed in the cgroup tree (deprecated)
          * %R: the root of this systemd's instance tree (deprecated)
          *
-         * %t: the runtime directory root (e.g. /run or $XDG_RUNTIME_DIR)
-         * %S: the state directory root (e.g. /var/lib or $XDG_CONFIG_HOME)
          * %C: the cache directory root (e.g. /var/cache or $XDG_CACHE_HOME)
-         * %L: the log directory root (e.g. /var/log or $XDG_CONFIG_HOME/log)
          * %E: the configuration directory root (e.g. /etc or $XDG_CONFIG_HOME)
-         * %T: the temporary directory (e.g. /tmp, or $TMPDIR, $TEMP, $TMP)
-         * %V: the temporary directory for large, persistent stuff (e.g. /var/tmp, or $TMPDIR, $TEMP, $TMP)
+         * %L: the log directory root (e.g. /var/log or $XDG_CONFIG_HOME/log)
+         * %S: the state directory root (e.g. /var/lib or $XDG_CONFIG_HOME)
+         * %t: the runtime directory root (e.g. /run or $XDG_RUNTIME_DIR)
          *
          * %h: the homedir of the running user
          * %s: the shell of the running user
          *
-         * %v: `uname -r` of the running system
-         *
          * NOTICE: When you add new entries here, please be careful: specifiers which depend on settings of the unit
          * file itself are broken by design, as they would resolve differently depending on whether they are used
          * before or after the relevant configuration setting. Hence: don't add them.
@@ -249,32 +233,35 @@ int unit_full_printf(const Unit *u, const char *format, char **ret) {
         assert(ret);
 
         const Specifier table[] = {
-                { 'n', specifier_string,                   u->id },
-                { 'N', specifier_prefix_and_instance,      NULL },
-                { 'p', specifier_prefix,                   NULL },
-                { 'P', specifier_prefix_unescaped,         NULL },
                 { 'i', specifier_string,                   u->instance },
                 { 'I', specifier_instance_unescaped,       NULL },
                 { 'j', specifier_last_component,           NULL },
                 { 'J', specifier_last_component_unescaped, NULL },
+                { 'n', specifier_string,                   u->id },
+                { 'N', specifier_prefix_and_instance,      NULL },
+                { 'p', specifier_prefix,                   NULL },
+                { 'P', specifier_prefix_unescaped,         NULL },
 
                 { 'f', specifier_filename,                 NULL },
+
                 { 'c', specifier_cgroup,                   NULL },
                 { 'r', specifier_cgroup_slice,             NULL },
                 { 'R', specifier_cgroup_root,              NULL },
 
-                { 't', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_RUNTIME) },
-                { 'S', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_STATE) },
                 { 'C', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_CACHE) },
-                { 'L', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_LOGS) },
                 { 'E', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_CONFIGURATION) },
-                COMMON_TMP_SPECIFIERS,
+                { 'L', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_LOGS) },
+                { 'S', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_STATE) },
+                { 't', specifier_special_directory,        UINT_TO_PTR(EXEC_DIRECTORY_RUNTIME) },
 
-                COMMON_CREDS_SPECIFIERS,
                 { 'h', specifier_user_home,                NULL },
                 { 's', specifier_user_shell,               NULL },
 
                 COMMON_SYSTEM_SPECIFIERS,
+
+                COMMON_CREDS_SPECIFIERS,
+
+                COMMON_TMP_SPECIFIERS,
                 {}
         };
 

src/cryptsetup/cryptsetup.c

@@ -353,7 +353,8 @@ static char *disk_mount_point(const char *label) {
 
         /* Yeah, we don't support native systemd unit files here for now */
 
-        if (asprintf(&device, "/dev/mapper/%s", label) < 0)
+        device = strjoin("/dev/mapper/", label);
+        if (!device)
                 return NULL;
 
         f = setmntent(fstab_path(), "re");
@@ -447,10 +448,9 @@ static int get_password(
 
                 assert(strv_length(passwords2) == 1);
 
-                if (!streq(passwords[0], passwords2[0])) {
-                        log_warning("Passwords did not match, retrying.");
-                        return -EAGAIN;
-                }
+                if (!streq(passwords[0], passwords2[0]))
+                        return log_warning_errno(SYNTHETIC_ERRNO(EAGAIN),
+                                                 "Passwords did not match, retrying.");
         }
 
         strv_uniq(passwords);

src/resolve/resolved-conf.c

@@ -230,14 +230,14 @@ int config_parse_dnssd_service_name(
                 void *userdata) {
 
         static const Specifier specifier_table[] = {
-                { 'm', specifier_machine_id,      NULL },
-                { 'b', specifier_boot_id,         NULL },
-                { 'H', specifier_host_name,       NULL }, /* We will use specifier_dnssd_host_name(). */
-                { 'v', specifier_kernel_release,  NULL },
                 { 'a', specifier_architecture,    NULL },
-                { 'o', specifier_os_id,           NULL },
-                { 'w', specifier_os_version_id,   NULL },
+                { 'b', specifier_boot_id,         NULL },
                 { 'B', specifier_os_build_id,     NULL },
+                { 'H', specifier_host_name,       NULL }, /* We will use specifier_dnssd_host_name(). */
+                { 'm', specifier_machine_id,      NULL },
+                { 'o', specifier_os_id,           NULL },
+                { 'v', specifier_kernel_release,  NULL },
+                { 'w', specifier_os_version_id,   NULL },
                 { 'W', specifier_os_variant_id,   NULL },
                 {}
         };

src/resolve/resolved-dnssd.c

@@ -157,14 +157,14 @@ static int specifier_dnssd_host_name(char specifier, const void *data, const voi
 
 int dnssd_render_instance_name(DnssdService *s, char **ret_name) {
         static const Specifier specifier_table[] = {
-                { 'm', specifier_machine_id,      NULL },
-                { 'b', specifier_boot_id,         NULL },
-                { 'H', specifier_dnssd_host_name, NULL },
-                { 'v', specifier_kernel_release,  NULL },
                 { 'a', specifier_architecture,    NULL },
-                { 'o', specifier_os_id,           NULL },
-                { 'w', specifier_os_version_id,   NULL },
+                { 'b', specifier_boot_id,         NULL },
                 { 'B', specifier_os_build_id,     NULL },
+                { 'H', specifier_dnssd_host_name, NULL },
+                { 'm', specifier_machine_id,      NULL },
+                { 'o', specifier_os_id,           NULL },
+                { 'v', specifier_kernel_release,  NULL },
+                { 'w', specifier_os_version_id,   NULL },
                 { 'W', specifier_os_variant_id,   NULL },
                 {}
         };

src/shared/install-printf.c

@@ -104,32 +104,18 @@ static int specifier_last_component(char specifier, const void *data, const void
 }
 
 int install_full_printf(const UnitFileInstallInfo *i, const char *format, char **ret) {
-        /* This is similar to unit_full_printf() but does not support
-         * anything path-related.
-         *
-         * %n: the full id of the unit                 (foo@bar.waldo)
-         * %N: the id of the unit without the suffix   (foo@bar)
-         * %p: the prefix                              (foo)
-         * %i: the instance                            (bar)
-
-         * %U the UID of the running user
-         * %u the username of running user
-         * %m the machine ID of the running system
-         * %H the hostname of the running system
-         * %b the boot ID of the running system
-         * %v `uname -r` of the running system
-         */
+        /* This is similar to unit_name_printf() */
 
         const Specifier table[] = {
+                { 'i', specifier_instance,            NULL },
+                { 'j', specifier_last_component,      NULL },
                 { 'n', specifier_name,                NULL },
                 { 'N', specifier_prefix_and_instance, NULL },
                 { 'p', specifier_prefix,              NULL },
-                { 'i', specifier_instance,            NULL },
-                { 'j', specifier_last_component,      NULL },
-
-                COMMON_CREDS_SPECIFIERS,
 
                 COMMON_SYSTEM_SPECIFIERS,
+
+                COMMON_CREDS_SPECIFIERS,
                 {}
         };
 

src/shared/specifier.h

@@ -37,24 +37,48 @@ int specifier_tmp_dir(char specifier, const void *data, const void *userdata, ch
 int specifier_var_tmp_dir(char specifier, const void *data, const void *userdata, char **ret);
 
 /* Typically, in places where one of the above specifier is to be resolved the other similar ones are to be
- * resolved, too. Hence let's define common macros for the relevant array entries. */
+ * resolved, too. Hence let's define common macros for the relevant array entries.
+ *
+ * COMMON_SYSTEM_SPECIFIERS:
+ * %a: the native userspace architecture
+ * %b: the boot ID of the running system
+ * %B: the OS build ID, according to /etc/os-release
+ * %H: the hostname of the running system
+ * %l: the short hostname of the running system
+ * %m: the machine ID of the running system
+ * %o: the OS ID according to /etc/os-release
+ * %v: the kernel version
+ * %w: the OS version ID, according to /etc/os-release
+ * %W: the OS variant ID, according to /etc/os-release
+ *
+ * COMMON_CREDS_SPECIFIERS:
+ * %g: the groupname of the running user
+ * %G: the GID of the running user
+ * %u: the username of the running user
+ * %U: the UID of the running user
+ *
+ * COMMON_TMP_SPECIFIERS:
+ * %T: the temporary directory (e.g. /tmp, or $TMPDIR, $TEMP, $TMP)
+ * %V: the temporary directory for large, persistent stuff (e.g. /var/tmp, or $TMPDIR, $TEMP, $TMP)
+ */
+
 #define COMMON_SYSTEM_SPECIFIERS                  \
-        { 'm', specifier_machine_id,      NULL }, \
+        { 'a', specifier_architecture,    NULL }, \
         { 'b', specifier_boot_id,         NULL }, \
+        { 'B', specifier_os_build_id,     NULL }, \
         { 'H', specifier_host_name,       NULL }, \
         { 'l', specifier_short_host_name, NULL }, \
-        { 'v', specifier_kernel_release,  NULL }, \
-        { 'a', specifier_architecture,    NULL }, \
+        { 'm', specifier_machine_id,      NULL }, \
         { 'o', specifier_os_id,           NULL }, \
+        { 'v', specifier_kernel_release,  NULL }, \
         { 'w', specifier_os_version_id,   NULL }, \
-        { 'B', specifier_os_build_id,     NULL }, \
         { 'W', specifier_os_variant_id,   NULL }
 
 #define COMMON_CREDS_SPECIFIERS                   \
         { 'g', specifier_group_name,      NULL }, \
         { 'G', specifier_group_id,        NULL }, \
-        { 'U', specifier_user_id,         NULL }, \
-        { 'u', specifier_user_name,       NULL }
+        { 'u', specifier_user_name,       NULL }, \
+        { 'U', specifier_user_id,         NULL }
 
 #define COMMON_TMP_SPECIFIERS                     \
         { 'T', specifier_tmp_dir,         NULL }, \

src/tmpfiles/tmpfiles.c

@@ -188,24 +188,26 @@ static int specifier_machine_id_safe(char specifier, const void *data, const voi
 static int specifier_directory(char specifier, const void *data, const void *userdata, char **ret);
 
 static const Specifier specifier_table[] = {
-        { 'm', specifier_machine_id_safe, NULL },
+        { 'a', specifier_architecture,    NULL },
         { 'b', specifier_boot_id,         NULL },
+        { 'B', specifier_os_build_id,     NULL },
         { 'H', specifier_host_name,       NULL },
         { 'l', specifier_short_host_name, NULL },
-        { 'v', specifier_kernel_release,  NULL },
-        { 'a', specifier_architecture,    NULL },
+        { 'm', specifier_machine_id_safe, NULL },
         { 'o', specifier_os_id,           NULL },
+        { 'v', specifier_kernel_release,  NULL },
         { 'w', specifier_os_version_id,   NULL },
-        { 'B', specifier_os_build_id,     NULL },
         { 'W', specifier_os_variant_id,   NULL },
 
-        COMMON_CREDS_SPECIFIERS,
         { 'h', specifier_user_home,       NULL },
 
-        { 't', specifier_directory,       UINT_TO_PTR(DIRECTORY_RUNTIME) },
-        { 'S', specifier_directory,       UINT_TO_PTR(DIRECTORY_STATE) },
         { 'C', specifier_directory,       UINT_TO_PTR(DIRECTORY_CACHE) },
         { 'L', specifier_directory,       UINT_TO_PTR(DIRECTORY_LOGS) },
+        { 'S', specifier_directory,       UINT_TO_PTR(DIRECTORY_STATE) },
+        { 't', specifier_directory,       UINT_TO_PTR(DIRECTORY_RUNTIME) },
+
+        COMMON_CREDS_SPECIFIERS,
+
         COMMON_TMP_SPECIFIERS,
         {}
 };

test/mkosi.default.networkd-test

@@ -8,7 +8,7 @@
 
 [Distribution]
 Distribution=fedora
-Release=32
+Release=33
 
 [Output]
 Format=raw_btrfs
@@ -57,6 +57,8 @@ BuildPackages=
         ninja-build
         pam-devel
         pcre2-devel
+        perl(IPC::SysV)
+        perl(Time::HiRes)
         pkgconfig
         python3-devel
         python3-lxml

units/systemd-journald.service.in

@@ -16,7 +16,6 @@ After=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-a
 Before=sysinit.target
 
 [Service]
-CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE CAP_SYSLOG CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_CHOWN CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE
 DeviceAllow=char-* rw
 ExecStart=@rootlibexecdir@/systemd-journald
 FileDescriptorStoreMax=4224
@@ -42,6 +41,11 @@ SystemCallFilter=@system-service
 Type=notify
 @SERVICE_WATCHDOG@
 
+# In case you're wondering why CAP_SYS_PTRACE is needed, access to
+# /proc/<pid>/exe requires this capability. Thus if this capability is missing
+# the _EXE=/OBJECT_EXE= fields will be missing from the journal entries.
+CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE CAP_SYSLOG CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_CHOWN CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE
+
 # If there are many split up journal files we need a lot of fds to access them
 # all in parallel.
 LimitNOFILE=@HIGH_RLIMIT_NOFILE@