The upstart program (”init”) emits a short list of events:
startup
stalled
control-alt-delete (formerly ctrlaltdelete or something similar)
kbdrequest
starting
started
stopping
stopped
(The last four relate to jobs. The first, startup, relates to init itself.)

The telinit program emits events named “runlevel”. (Formerly runlevel-/n/.)

The initctl program emits events with arbitrary names specified on the command line. This can be used in various scripts under /etc, e.g. on my Fedora12,
/etc/gdm/Init/Default:initctl -q emit login-session-start DISPLAY_MANAGER=gdm.

Events don’t just have names, they have also arguments – a list of arbitrary strings, and “environment variables”. Job files specify “start on xxx” and “stop on xxx”, where xxx are specifications that can match a number of events. I suppose that when an event happens init checks all such start/stop on specifications to see if they should be triggered. The name must match exactly, the following words are “file globs” that are matched against successive arguments of the event. Events with too few args do not match.

There is just one thing I have found in the code that I had not become aware of reading the docs: If an event emission is considered “failed” (I am unsure what exactly the criteria are) a new event is automatically emitted with “/failed” appended to the name, and with the same arguments and environment. (If the “name/failed” event fails no new event is emitted.)

I suggest something is added to the documentation in the spirit of this reply, to give the reader a feeling of having a handle on the set of possible events and where to look for user-defined events.

I had to implement something similar (I wanted a web interfact to start/stop certain jobs – namely, multiplayer game servers)

I wrote a helper script that would accept 2 parameters (jobname, and “start” or “stop”) and, if the jobname matches a list, would run the specified command. You can’t make scripts setuid, so instead I added the following line to /etc/sudoers:

%www-data ALL=NOPASSWD: /path/to/script

that lets anyone in the www-data group run my script as root using sudo, without a password (I needed that because it was being ran by web scripts; you probably don’t)

I’d imagine this is less than idea for your purposes (I assume you want users to be able to add their own jobs, and you also want the jobs to run as that user, rather than root)

I went to a great deal of difficulty to get a device that doesn’t require me to be root to init it…and I’m seeing several different ways suggested to pull it off.

Is there a facility for a user’s job (as opposed to a root job) to be called out there?

In man events: “upstart works on the basis of event files that describe jobs that should be managed”
How come a file holding the entire description of one and only one job is called an “event” file? Wouldn’t be “job file” more intuitive?

I can imagine that changing a directory name would be too disruptive. But please at least fix the terminology in the documentation.

In the other corner, we have “events” that are POSSIBLE because of (1)our hardware, (2) our behavior, (3) installed software packages, (4) our behavior, er — use of installed software.

QUESTION: How do we learn — other than source — about the list of POSSIBLES? Are we forced to read source code for device drivers? Can ’strings’ or similar help us inspect binaries? If so, what are we looking for?

RATIONALE: I have this workstation. It has all sorts of knobs and buttons. Some fire “events”. Others do not fire “events”. What causes/configures Fn+F7 to throw an “event” while “Alt+F7″ does nothing?

Wanting to learn. Willing to write!! Needing information.
~~~ 0;-s

A question. Suppose I have a service that uses lots of wrappers to start. I use a “script” instead of an “exec” to start it, and from that script I call the topmost wrapper. So it is going to fork a few times before it actually starts the service. When I call stop, the “script” gets killed, but not the service.

Worse still, my service requires special handling to be stopped. I can’t just send it a kill, I need to run a command. Suppose it’s a kernel module or a driver that I’m running.

How can I specify the means to stop the service? Is there a “stop” section for that, as there is “script” in addition to simply “exec” to specify how to start?

Or should I let Upstart simply kill the “script” section and do the actual killing in post-start?

I don’t want to employ dirty hack. What is the intended way?

Thanks!
Alex

I’ve done some very sophisticated embedded system event driven applications. For what I know about upstart, it will be a wonderful improvement. We need help to watch the bouncing balls and work with this thing.

~~~ Saint 8d;-)

Is this the only/best documentation available for writing jobs (other than the source I mean)?

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

While there is a very good getting started guide on this webite, it is pretty much the only documentation that exists, and it _IS_ only useful for getting started, not finished. “man event.d” does nothing, “man upstart” does nothing, “man init” leads via the “see also” section to initctl, which is interesting but also doesn’t help in writing the things. The example jobs are of the very simple kind and are similarly unhelpful. (The existance of a pre-stop script and a post-start was inferred from the existing examples, but aren’t explicitly mentioned anywhere)

Just from what has been casually dropped in here and on I know there’s a “task” keyword, but have no idea what that means. There are tantalising hints to some kind of logging facility (which is what I’m tearing my hair out over at the moment) but I have no idea how to invoke it, or even to redirect output somewhere sensible, other than redirecting at the end of the line calling the program (which then triggers that app’s very annoying let’s-buffer-1-screen-at-a-time mode). If I put the app at the beginning of a pipe, stopping the job kills the shell that’s calling the program without killing the program itself and I have no idea how to fix it. I have no clue what events might fire on my system, or what might decide to fire them, and have no systematic way of finding out. I have no idea how to carry state information forward from pre-start scripts to the start script itself, other than creating tons of temp files.

In short, I need documentation