In the last post we took a look at how matching of events in jobs is often misunderstood, in this and the next few posts we’ll take a look at events themselves and the different ways they can be used.
The most obvious way that one can use Events, and I think that this is the way that most people instinctively understand about the system, is as Signals.
What do I mean by a Signal? If you’ve done any programming in Qt, GTK+ or even just used D-Bus you’ll probably already know exactly what I mean. They’re pretty much like good old fashioned UNIX signals too, except that they’re not predefined. If you’ve done programming in ObjectiveC, the analog is Notifications.
A signal is simply a notification that something happened on the system, it may contain additional information about what happened, and it may or may not have an opposite signal indicating that whatever state the signal announced is no longer true.
The most important things about signals is that they have no duration and no follow-up. The announcer of a signal cares not whether anybody cared about it, and doesn’t wait around to see whether anything happened. As far as the announcer cares, it’s informational only.
Let’s take a look at one of the most obvious examples of a signal event on your system, control-alt-delete. This event is emitted (by Upstart itself) every time the Control-Alt-Delete keyboard combination is caught by the kernel. You probably have a job called /etc/init/control-alt-delete.conf on your system that contains something like:
start on control-alt-delete exec shutdown -r now "Control-Alt-Delete pressed"
Remember that the names of jobs and events are completely independent, in order for this job to be run when Control-Alt-Delete is pressed is needs that start on control-alt-delete line inside it.
You can disable this job and replace it with whatever you like, and you can press Control-Alt-Delete on your keyboard as many times as you like — you’ll get an event each time it’s pressed. The important thing is that Upstart doesn’t care whether or not this event is handled or not.
Signal events don’t have to be as trivial either, there’s a collection of signal events that are critical to booting your system: virtual-filesystems, local-filesystems, remote-filesystems and filesystem. These events are emitted by the mountall utility as it mounts the different components of the filesystem, and are expected to result in other Upstart jobs being started that bring up the rest of the system afterwards.
But mountall itself doesn’t care whether you do that, it’s just informing you that it’s performed part of its job and is now moving on. An equally critical signal event like this is the startup event emitted by Upstart itself.
So far none of these events has had any arguments, and none of them have had any opposite event; let’s look at another set of examples from your system that have both. These come from the upstart-udev-bridge which we’ll be looking at in more detail in a few weeks.
Let’s look at the net-device-added event, this is a signal to indicate that udev has finished processing an add action for a device in the net subsystem. It has a collection of interesting environment variables that all come from udev:
INTERFACE=wlan0 IFINDEX=3 ID_VENDOR_FROM_DATABASE=Intel Corporation ID_MODEL_FROM_DATABASE=PRO/Wireless 3945ABG [Golan] Network Connection ID_BUS=pci ID_VENDOR_ID=0x8086 ID_MODEL_ID=0x4222
Again, this is just a signal to the system that a network device was added but it contains lots of useful information about the network device. It also has an opposite event, net-device-removed that indicates the equivalent device was removed from the system, which has much of the same environment.
We use this to bring up network interfaces, your system probably has /etc/init/network-interface.conf with something like the following:
start on net-device-added stop on net-device-removed INTERFACE=$INTERFACE instance $INTERFACE pre-start exec ifup --allow auto $INTERFACE post-stop exec ifdown --allow auto $INTERFACE
There’s lots of interesting things about this job, it’s an instance job and it uses a boundary pattern, both of these things will be introduced in future blog posts. For now let’s just focus on the fact the job is started when a network device is added to the system, and is stopped again when the same network device is removed (remember we covered this symmetrical matching in the previous blog post).
Remember the started and stopped events? They behave like signals too.
So how do you emit a signal event of your own, after all, Upstart is designed to be extended in this way. Simply use the initctl emit command with the –no-wait option:
root@worldofgoo:~# initctl emit --no-wait surprise root@worldofgoo:~#