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
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;
Bshouldn'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
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.
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
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.)