[Solved] systemd does not wait for the unit to finish

Question

My problem is described in the title. I have made a test by enabling the following unit:
[Unit]
Description=/etc/rc.local Compatibility
[Service]
Type=forking
ExecStart=/bin/sleep 1000
TimeoutSec=0
RemainAfterExit=yes
After=network.target
[Install]
WantedBy=multi-user.target
The unit is well started (a process sleep 1000 exists). But with a type=forking, systemd is supposed to hang in this case. Instead, the graphical.target is launched, systemctl list-units mention it as dead, but the display manager is started before the sleep 1000 completes. Ho can I force systemd to wait?
Last edited by olive (2015-03-16 16:49:34)

Answer 1

olive, now you're making even less sense. I didn't say the sleep example was stupid and I didn't question your reasons for doing/wanting this.
I suggested you add "Before=display-manager.service" and you respond "I added Before=graphical.target and it didn't change anything."
I also tried to explain why systemd has no reason to delay the display-manager.service. You could have asked for further clarification, as berbae has now done. Let's try a longer explanation.
Service startup
Services can be started in different ways, as configured with Type=. This determines when a service is considered "started" (or when the service's start-up is considered finished). When a service reaches this state (some time after being started), units that are supposed to start After= this service will be started (and no sooner).
With simple systemd has no further information about the start-up process. It launches whatever you specify in ExecStart and this is the main process that continues to run till the service stops. systemd assumes this type of service is started immediately. All the other types have some way for the process to indicate to systemd (either directly or indirectly) when it has finished starting.
Actually oneshot is also a bit special and that is where RemainAfterExit comes in. For oneshot, systemd waits for the process to exit before it starts any follow-up units (and with multiple ExecStarts I assume it waits for all of them). So that automatically leads to the scheme in berbae's last post. However, with RemainAfterExit, the unit remains active even though the process has exited, so this makes it look more like "normal" service with
begin of unit/startup ---- end of startup ------ end of unit
This is the relevant behavior for this thread. First sleep starts, then after 1000 seconds, start-up finishes and follow-up units will be started. Then either the unit dies, or (with RemainAfterExit) it stays "active".
The man page describes how "end of startup" is determined for each Type.
Targets
Targets are meant to group units together, to provide synchronization points (and replace runlevels). When you start a target, all its units will be started (in parallel if possible). The man page says:
Unless DefaultDependencies= is set to false, target units will
       implicitly complement all configured dependencies of type Wants=,
       Requires=, RequiresOverridable= with dependencies of type After= if the
       units in question also have DefaultDependencies=true.
This means that (by default) when a target is requested, all it units are started first. Only after all units have finished starting, the target itself will be started (and since the target doesn't do anything by itself, this startup is basically instantaneous). Without this dependency, the order between the target and its units is unspecified, so in theory the target could finish starting immediately while its units are still being started.
Back to olive
graphical.target has these DefaultDependencies, so it is not started until all its units (like display-manager.service) and other After= dependencies (like multi-user.target) have finished starting. Your sleep service has to be started before multi-user.target starts (again due to default target dependencies). So first display-manager and the sleep service are started and after 1000 seconds, the sleep service finishes starting and then (assuming all other dependencies were quicker) multi-user.target is started and graphical.target as well (assuming display-manager didn't need 1000 seconds).
If you want display-manager.service after the sleep service, add a Before/After line to specify that (this was your original goal and my suggestion).
olive wrote wrote:However, units that are parts of the graphical target are still launched before the graphical target become active. I am still unable to completely delay the starts of the graphical target before a specific unit completes.
It should be clear now how this works. "units that are part of the graphical target" can only mean "units that are wanted/required by the graphical target" but that is basically all the units that are started when you boot your system, because multi-user.target is a part of graphical.target. And your sleep service is a part of multi-user.target, so in fact you're saying you want to delay starting the sleep service until the sleep service completes
What you probably intended was to delay all units that are a part of graphical.target but not of multi-user.target until after the sleep service. I can't think of an easy (or even good) way to do this and this post is already too long, so I'll table that for now.