Bug#727708: upstart dependency handling
I wanted to lift this out of the thread it was buried in and see if I'm
understanding it correctly, since if I am, it seems like a significant
issue.
Cameron Norman <camerontnorman@gmail.com> writes:
> I think you raise a lot of good points in this email, but here you are
> saying something which may demonstrate your (understandable) confusion
> about the Upstart event model. Upstart does not treat dependencies as
> events. Often times, Upstart //jobs// treat dependencies as events (and
> the ones you wrote below do), but events do not signal a
> dependency. Just because you said that jobOne starts with jobTwo does
> not mean that jobOne needs jobTwo, just that during boot up jobOne will
> start with jobTwo. To express a dependency, jobTwo needs to have a
> "start on (event where I am needed)". If, for example, jobOne depends on
> a dbus interface of jobTwo, then jobTwo could have a "start on dbus ..."
> to show that dependency.
But does that actually provide a dependency? In other words, if the
sysadmin manualy starts jobTwo, does that either prevent jobTwo from
starting becaus the dbus service isn't available, or start the dbus
service? Or is jobTwo just started without dbus to cope as best it can?
Having actual dependencies strikes me as an important technical feature.
I don't like the idea of the init system not caring about whether the
prerequisites for a job are met and just blindly starting it anyway.
We're all somewhat used to that behavior, since that's what we get with
sysvinit, but it's inherently fragile. We can try to hold all software
packaged in Debian to the standard that it will fail cleanly and without
problems if started in the wrong sequence, but it still seems to preserve
the possibility of a whole class of bugs that systemd would close.
Assuming, that is, that the understanding expressed on this thread is
correct.
Note that dependency handling is relevant to socket activation as well.
As I discovered when experimenting with systemd, for reproducible
behavior, you want to ensure that the job is always started with socket
activation if that's how you have it configured; if not, such things as
bind addresses may not be honored, which could even pose security issues.
That includes the case where the job is configured to not start by default
but is manually started by the administrator.
Now, you could introduce a new dependency model just for socket activation
or treat socket activation as part of that service rather than (as systemd
does) a separate service that's tightly coupled with the daemon. So this
is addressable by making socket setup a special case of sorts, such as by
converting the request for the socket into a method event that is
triggered before starting the daemon itself. But all that does feel
harder to understand to me, particularly since you really want the sockets
started independently of the jobs and early in the boot process so that
other services can start talking to them, which makes the method call
approach tricky.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: