Two other random thoughts:

If you haven’t already, I think you should consider the concept of job name aliases. For example, needing an e-mail MTA isn’t the same as tomcat needing apache. I want to be able to say “start on started mailmta” so that my package doesn’t have to be updated when a new MTA is added or the default MTA is changed. You gave an example of doing that with an exported environment variable, but that seems kludgy to me.

You might want to consider “requires”, “needs”, or something similar as syntatic sugar for start on started, stop on stopping. I know you didn’t want to make it look like a dependency tree, but it’s going to happen so often that something simpler may be warranted in this case. Particularly since it’s already been noted there could be confusion over starting, started, stopping, stopped.

No, the proper thing to do is keep all the information about what a daemon needs *with that daemon*.
It’s not about “oh, it’s so beautifully symmetric”, it’s about “it’s maintainable, and I don’t have things strewn across the disk that I will never find”.
You should have ’start portmap on starting’ for that case.

As to whether it’s starting, I would suggest: shared library that parses and handles adding and removing these dependencies and queries them, and a tool that uses that library for command line users (or a graphical tool, either way, both would use the library). The former would be used by installers and the latter by end users. That way you can change the format, not worry about parsing, etc. Hmm, actually, if it was all done by a library the symmetry could probably be maintained if you wanted while being able to do proper uninstalls.

Biggest problem on *nix is users/scripts directly altering what should be private data structures. Should be via a library supplied with the tool that needs the data every time IMO…

There’s no cyclic issues or graph resolution because there’s no cycle or graph. A is started, which emits the starting A event, which starts B. B starting emits the starting B event, but that has no effect on A since it’s already started. B finishes starting, unblocking A, and allowing it to finish starting.

This is one of the elegancies of the event-based model.

Of course, there is one way to loop it, job A would have:

start on stopping B
stop on starting B

and job B would have:

start on stopping A
stop on starting A

Such a definition would create two jobs that flip-flopped between each other, but that’s a perfectly valid service model — one of “failover”

Fortunately Upstart can do ordinary provision/requirement relationships, I just didn’t want to document them in the blog because you should try to never use this kind of thing.

Remember that the job name is just one parameter to the “starting” event, there are others and you can add any additional ones you want with the “export” variable.

So our nfs-server job could add a parameter to its starting event:

env REQUIRE_PORTMAP=1
export REQUIRE_PORTMAP

That the portmap job could pick up and match:

start on starting REQUIRE_PORTMAP=1

Minor nitpick - Semantic difference on start[ed|ing] is a bit hard read. I know it is the current signal/event names. But explicitly denoting the difference of starting as “before”, and started as “after”? Or maybe something else

start after dbus vs. start on starting dbus.
start before nfs-server vs. start on started nfs-server.
There might be other problems with this though, like not matching event names.

Make it easy to write/select the correct configuration - it would be nice. Very un*nix, but still nice

Perhaps an equivalent of the “provides:” package management directive would make sense here, so portmap could say “start on starting portmap-user” and have nfs-server say that it is a “portmap-user”?