well, afaict from your description the information "A needs B" is
totally implicit, there is no place where this info is available, so no
way to pass that info to systemd.
That means that the only way to fix that without explicitely telling
someone about the dependency is to allow dbus to start units while its
shutdown is pending
this seems to be explicitely forbidden, so my guess is that there are
very good reasons for that and there is little chances that there is a
so, i'm not an expert, but I would be very suprised if there was a way
to do that... an explicit "allow startup during termination" flag in the
auto-activation .service file could be a way around but I don't think
such file exists...
Post by Michal KoutnÃ½
I'd like to ask your opinion on the following situation.
B.service exposes its API through D-Bus. A.service uses this API and
thus it has a dependency on B.service. This is implicit though -- and
we're happy we can rely on D-Bus activation and needn't to list all
As it comes, A.service needs B.service for proper termination. During
the shutdown transaction there is unspecified ordering of the two (since
the dependency is implicit only) and B.service is stopped before A.service.
A.service would attempt to D-Bus-activate B.service but that is rejected
because dbus-daemon will eventually stop too. Note this doesn't mean
dbus-daemon is already handling SIGTERM, it's because a dbus-daemon stop
job is pending . A.service may thus cannot terminate properly.
I know this could be circumvented by explicitly specifying
After=b.service for the A.service but denies the elegance of the lazy
Are there any better ways how to deal with this?
P.S. FTR, in my case A.service=libvirtd.service and
systemd-devel mailing list
20 rue des Jardins
Responsable de l'expertise Smile-ECS
email ***@smile.fr <mailto:***@smile.fr>
Twitter <https://twitter.com/GroupeSmile> Facebook
DÃ©couvrez lâunivers Smile, rendez-vous sur smile.eu
eco Pour la planÃšte, n'imprimez ce mail que si c'est nÃ©cessaire