View Issue Details

IDProjectCategoryView StatusLast Update
0018309CentOS-7systemdpublic2021-09-27 07:00
Reportersorinm Assigned To 
Status newResolutionopen 
PlatformUbuntuOSCentosOS Version7
Product Version7.9.2009 
Summary0018309: systemctl start does not respect services start order specified in .service
Descriptionsystemctl start does not respect services start order specified in .service

Service A set to start before service B in .services file
A.service :
Description= service A

Description= service B

systemctl enable A.service B.service
systemctl start A.service B.service

Expected behaviour :

A starts, A sleep 5s (in main.cpp) , then send notification (call sd_notify), and then B starts

Unexpected behaviour :

A and B start at the same time without waiting
If the vm is rebooted, systemd starts A and B (because of the previous systemctl enable) and in that case A starts, wait 5s, send notification and then B starts. If both services are manually stopped and started (systemctl start A.service B.service , both in the same cmd) A and B start at the same time without waiting for the notification from A.

After and Before are respected when using systemctl start A.service B.service if there is Requires=A.service in B.service Unit.
Steps To ReproduceSet the .services files
systemctl enable A.service B.service
systemctl start A.service B.service
Additional InformationThe documentation specify that After and Before can be used without requires :
Before=, After=
These two settings expect a space-separated list of unit names. They may be specified more than once, in which case dependencies for all listed names are created.
Those two settings configure ordering dependencies between units. If unit foo.service contains the setting Before=bar.service and both units are being started, bar.service's start-up is delayed until foo.service has finished starting up. After= is the inverse of Before=, i.e. while Before= ensures that the configured unit is started before the listed unit begins starting up, After= ensures the opposite, that the listed unit is fully started up before the configured unit is started.
When two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. I.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down. Given two units with any ordering dependency between them, if one unit is shut down and the other is started up, the shutdown is ordered before the start-up. It doesn't matter if the ordering dependency is After= or Before=, in this case. It also doesn't matter which of the two is shut down, as long as one is shut down and the other is started up; the shutdown is ordered before the start-up in all cases. If two units have no ordering dependencies between them, they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit type when precisely a unit has finished starting up. Most importantly, for service units start-up is considered completed for the purpose of Before=/After= when all its configured start-up commands have been invoked and they either failed or reported start-up success. Note that this does includes ExecStartPost= (or ExecStopPost= for the shutdown case).
Note that those settings are independent of and orthogonal to the requirement dependencies as configured by Requires=, Wants=, Requisite=, or BindsTo=. It is a common pattern to include a unit name in both the After= and Wants= options, in which case the unit listed will be started before the unit that is configured with these options.
TagsNo tags attached.


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2021-09-22 13:37 sorinm New Issue