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 <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
