Dependency-based vs. Event-driven

[Scott James Remnant]

I've mentioned a few times that upstart should be an event-driven init
system, not a dependency-based one, but I've never really elaborated on
what the difference is and why I think it's important.


Let's examine how a dependency-based system works first.

Each service declares its dependencies, lists of other services that
need to be started first.

In order to start a service, you first starts its dependencies.

This also means that you don't start a service unless it's explicitly
requested, or is a dependency of something else.


So take the task of booting up, init starts ... and that's all that
happens.  It waits for a service to be started before doing anything.

There appear to be two ways people work around this fact:

 1) start all services that the system knows about (SMF)

 2) start a known "goal" service (initNG)


The problem with the first technique is obvious, you have to go to extra
steps to mark the difference between a service that is broken and a
service that should only be started manually.  There is no way to have
different profiles of services to be started.

The second technique solves this issue, you don't list the service as a
dependency of the goal.  However now you have a new headache, every time
you add a new service you have to remember to add it to the goal.
You're no better off than when you had symlinks in rc2.d


There's also another problem with dependency-based systems, and that is
that while they are perfect for "custom" systems (Gentoo), I don't think
they work well for "default" configurations.

Take gdm for example, it's initially clear that dependencies of this
include writable filesystems.  However you may also need other
dependencies, for example on the nvidia kernel module being loaded, or
maybe even a sound card, dbus, etc. being loaded.

And then what if the sound card fails for some reason?  Now gdm won't
start because one of its dependencies has failed to start.  Having gdm
refuse to start simply because your default sound card isn't connected,
or you don't have a sound card, seems to be a little brittle.


So what's event-driven init then?

It's a subtly different way of looking at things; services aren't
started because they're a boot-time goal, they are started because
something happened that they react to.

Networking isn't a dependency of Apache, but if we bring networking up
we want to start apache if it isn't already running.

Nvidia drivers aren't a dependency of gdm, but once we've loaded the
driver we try to start gdm if it isn't already running.

There may be other reasons to start Apache, it might react to the
"filesystems mounted and writable" event; but the system administrator
can customise that.

There would also be other reasons to start gdm; probably the same event,
in fact.


Another example; your iPod being connected isn't a dependency of
podcastd ... that's not anything the init system can influence.  But we
want podcastd to be started if and when your iPod is connected.


The different is very subtle, and it may seem like there are other
solutions to the dependency-based idea; however after much thought I am
increasingly convinced that reaction to events is the correct way to go.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20060609/06243752/attachment.pgp