It seems as if the accepted way to specify a dependency of service A
on service B
in upstart is to work in the reverse dependency direction: give service B
a start on starting A
stanza.
I'd like to avoid that for two reasons:
It seems bizarre to modify
B
's config file when a new service that depends on it comes along: the new service should declare its dependencies;B
shouldn't have to know about them.I'd like to automate the construction of service hierarchies by proceeding topologically from a dependency graph which is already constructed and it would be inelegant to have to convert it into a reverse dependency graph just for this.
I thought I could just start the dependent services in a pre-start
script stanza in the conf file, but it appears that that won't work if I also have setuid
and setgid
stanzas---since then the pre-start
script would be run with that user/group.
Is there an idiomatic way to do this (i.e. declare dependencies rather than reverse dependencies)? This answer is not what I want since I don't want to also have to write a non-upstart init script.
(I suppose start on started B
for A
would work in this case, but I'm not sure if that would work if A
had multiple dependencies: would start on started B and started C
work? If I start B
and then C
, will A
get both events at once?Also this gets the logic wrong even in the one-dependency case: start on started B
says that B
's having started is a sufficient condition for starting A
. But I want to say that B
's having started is a necessary condition for starting A
, and a condition that the action of starting A
should make true.)