systemd System and Service Manager
+CHANGES WITH 240 in spe:
+
+ * A new service type has been added: Type=exec. It's very similar to
+ Type=simple and ensures the service manager will wait for both fork()
+ and execve() of the main service binary to complete before proceeding
+ with follow-up units. This is primarily useful so that the manager
+ propagates any errors in the preparation phase of service execution
+ back to the job that requested the unit to be started. For example,
+ consider a service that has ExecStart= set to a file system binary
+ that doesn't exist. With Type=simple starting the unit would
+ typically succeed instantly, as only fork() has to complete
+ successfully and execve() is not waited for, and hence its failure is
+ seen "too late". With the new Type=exec service type starting the
+ unit will fail, as the execve() will be waited for and will fail,
+ which is then propagated back to the start job.
+
+ NOTE: with the next release 241 of systemd we intend to change the
+ systemd-run tool to default to Type=exec for transient services
+ started by it. This should be mostly safe, but in specific corner
+ cases might result in problems, as the systemd-run tool will then
+ block on NSS calls (such as user name lookups due to User=) done
+ between the fork() and execve(), which under specific circumstances
+ might cause problems. It is recommended to specify "-p Type=simple"
+ explicitly in the few cases where this applies. For regular,
+ non-transient services (i.e. those defined with unit files on disk)
+ we will continue to default to Type=simple.
+
CHANGES WITH 239:
* NETWORK INTERFACE DEVICE NAMING CHANGES: systemd-udevd's "net_id"
* systemd-resolved.service and systemd-networkd.service now set
DynamicUser=yes. The users systemd-resolve and systemd-network are
- not created by systemd-sysusers.
+ not created by systemd-sysusers anymore.
+
+ NOTE: This has a chance of breaking nss-ldap and similar NSS modules
+ that embedd a network facing module into any process using getpwuid()
+ or related call: the dynamic allocation of the user ID for
+ systemd-resolved.service means the service manager has to check NSS
+ if the user name is already taken when forking off the service. Since
+ the user in the common case won't be defined in /etc/passwd the
+ lookup is likely to trigger nss-ldap which in turn might use NSS to
+ ask systemd-resolved for hostname lookups. This will hence result in
+ a deadlock: a user name lookup in order to start
+ systemd-resolved.service will result in a host name lookup for which
+ systemd-resolved.service needs to be started already. There are
+ multiple ways to work around this problem: pre-allocate the
+ "systemd-resolve" user on such systems, so that nss-ldap won't be
+ triggered; or use a different NSS package that doesn't do networking
+ in-process but provides a local asynchronous name cache; or configure
+ the NSS package to avoid lookups for UIDs in the range `pkg-config
+ systemd --variable=dynamicuidmin` … `pkg-config systemd
+ --variable=dynamicuidmax`, so that it does not consider itself
+ authoritative for the same UID range systemd allocates dynamic users
+ from.
* The systemd-resolve tool has been renamed to resolvectl (it also
remains available under the old name, for compatibility), and its