Abstract upstart jobs and events

[Clint Byrum]

During boot, a number of very important things happen that will cause
jobs to be started, and are emitted as events.

local-filesystems
filesystem
mounted DEVICE=DEVICE MOUNTPOINT=MOUNTPOINT TYPE=TYPE OPTIONS=OPTIONS
net-device-up IFACE=xxx
runlevel 2

Some of these have man pages, some do not.

As we convert jobs to upstart, its not always clear exactly which events
to tie into for start on and stop on.

The traditional wisdom has been that a network service which stores
things locally uses


start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [016]


This is fine to those of us gaining a deep familiarity with upstart and
how its used in Ubuntu, but it makes very little sense to a sysadmin
reading /etc/init/squid.conf and wondering why their squid proxy failed.

Furthermore, being explicit gives us no chance to add more criteria or
tasks to be run on these events! For instance, there are a couple of
bugs where upstart jobs are still running, their daemons responding to
the SIGTERM sent at runlevel 0/runlevel 6, when umountfs finishes
unmounting. This causes FS's to be shutdown dirty, requiring fsck on the
next boot. It seems to me that the right way to handle this is for these
to change

stop on runlevel [016]

to

stop on unmounting-filesystems

And then have umountfs emit and wait for unmounting-filesystems before
it actually unmounts the filesystems.

However, really, what would make even more sense would be to have
abstract jobs and/or events for major system state transitions.

start on starting network-services
stop on stopping network-services

This way there's just one job in /etc/init/network-services.conf:

description "Abstract job to aggregate all network services"

start on filesystem and net-device-up IFACE!=lo
stop on unmounting-filesystems


These may not be the perfect generic start on / stop on events, but by
putting them here, and transitioning all other upstart jobs that are
similar to this to following this job, we can correct that mistake
later, and (perhaps more importantly) a system administrator can
customize their service startup easily.

Thoughts?