diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index b09cdd4ecf..e37de65a77 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -161,11 +161,13 @@
, or :
- If set to (the default if ExecStart= is
- specified but neither Type= nor BusName= are), the service manager
- will consider the unit started immediately after the main service process has been forked off.
- The use of this type is discouraged, use instead.
-
+ If set to (the default if ExecStart=
+ is specified but neither Type= nor BusName= are), the
+ service manager will consider the unit started immediately after the main service process has
+ been forked off (i.e. immediately after fork(), and before various process
+ attributes have been configured and in particular before the new process has called
+ execve() to invoke the actual service binary). Typically,
+ Type= (see below) is the better choice, see below.It is expected that the process configured with ExecStart= is the main
process of the service. In this mode, if the process offers functionality to other processes on
@@ -268,13 +270,15 @@
anyway.
- It is generally recommended to use Type= for
- long-running services whenever possible, as it is the simplest and fastest option. However, as this
- service type won't propagate service start-up failures and doesn't allow ordering of other units
- against completion of initialization of the service (which for example is useful if clients need to
- connect to the service through some form of IPC, and the IPC channel is only established by the
- service itself — in contrast to doing this ahead of time through socket or bus activation or
- similar), it might not be sufficient for many cases. If so, ,
+ It is recommended to use Type= for long-running
+ services, as it ensures that process setup errors (e.g. errors such as a missing service
+ executable, or missing user) are properly tracked. However, as this service type won't propagate
+ the failures in the service's own startup code (as opposed to failures in the preparatory steps the
+ service manager executes before execve()) and doesn't allow ordering of other
+ units against completion of initialization of the service code itself (which for example is useful
+ if clients need to connect to the service through some form of IPC, and the IPC channel is only
+ established by the service itself — in contrast to doing this ahead of time through socket or bus
+ activation or similar), it might not be sufficient for many cases. If so, ,
, or (the latter only in case the service
provides a D-Bus interface) are the preferred options as they allow service program code to
precisely schedule when to consider the service started up successfully and when to proceed with
@@ -282,12 +286,17 @@
explicit support in the service codebase (as sd_notify() or an equivalent API
needs to be invoked by the service at the appropriate time) — if it's not supported, then
is an alternative: it supports the traditional heavy-weight UNIX service
- start-up protocol. Note that using any type other than
- / possibly delays the boot process, as the service
- manager needs to wait for service initialization to complete. (Also note it is generally not
- recommended to use or for long-running services.)
-
-
+ start-up protocol. Note that using any type other than possibly delays the
+ boot process, as the service manager needs to wait for at least some service initialization to
+ complete. (Also note it is generally not recommended to use or
+ for long-running services.)
+
+ Note that various service settings (e.g. User=, Group=
+ through libc NSS) might result in "hidden" blocking IPC calls to other services when
+ used. Sometimes it might be advisable to use the service type to ensure
+ that the service manager's transaction logic is not affected by such potentially slow operations
+ and hidden dependencies, as this is the only service type where the service manager will not wait
+ for such service execution setup operations to complete before proceeding.