The man page
systemd.service(5) explains the
Type options for services:
Configures the process start-up type for this service unit. One of
If set to simple (the default if neither
ExecStart=are specified), 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 the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units.
This implies to me that systemd won't start the units in parallel here. Also here:
If set to
forking, it is expected that the process configured with
fork()as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the
PIDFile=option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.
In other words, according to this man page systemd executes the service units sequentially? So when systemd activates a daemon process, it waits for it before it activiates follow up units? Doesn't make sense at all.
Type affects the startup procedure of other units?