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.

I want to trigger a script when a device (.f.ex. usb dongle, usb bluetooth etc) i removed. I read that upstart can be triggert on these events (emitet by the kernel, hal or dbus) but i do not know the name “?” of the event to trigger on. Could you help me out there? /giko

Next how do I write a Upstart init.d file to replace a SYSV formatted file I used under Fedora, or a Debian based init.d for Ubuntu? Again, an example would be nice. I can supply an autotools package with debian|redhat.initd templates, and two versions of the same C template daemon; libc & glib based with only –userid username –version –force (pid create) –help, if that would help. Its on my sourceforge page with gapcmon. gdaemons-0.1.1.tar.bz2 https://sourceforge.net/project/showfiles.php?group_id=157888&package_id=280067&release_id=606274

I ask because I am interested in what your doing and there is a benefit for me; one init.d script for all linux platforms (WooHoo). Thus, I want to understand how the two or three daemons I have released will be advantaged by upstart. I have no problem adding dbus, although I already create a pid file. Also I always fork once, but that two can be changed. I’m looking for the book or some best practces that I can code to. Most of what i have googled on UpStart has been difficult to piece together and code to.

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…

on started mysql does not work for me?
Any ideas?

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