[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upstart: please update to latest upstream version

On Fri, Feb 24, 2012 at 10:55:46PM +0100, Thomas Hood wrote:
> On Fri, Feb 24, 2012 at 20:17, Steve Langasek <vorlon@debian.org> wrote:
> > On Thu, Feb 23, 2012 at 11:58:08AM +0100, Goswin von Brederlow wrote:

> >> Upstart also does not support Should-Start which makes it impossible to
> >> provide corect init scripts for a number of services. For example autofs
> >> will not work if it uses nis because nis is not started before
> >> autofs. Due to the lack of Should-Start the only way to get nis to start
> >> before autofs would require autofs to depends on nis.

> > The way to express this in upstart is to declare nis 'start on starting
> > autofs or runlevel [2345]'.  The relationship is written in the opposite
> > direction compared with LSB init scripts, but is no less flexible.

> This will, however, start nis in parallel with autofs, whereas what is
> probably wanted is that nis be up and running before autofs is
> started.

Well, I fudged a little here.  You're right that, as written above, nis is
not guaranteed to start before autofs.  Due to a (well-understood and
recognized) limitation of upstart's current event handling, if the
'runlevel' event is seen before 'starting autofs', the subsequent 'starting
autofs' event will *not* block waiting for nis to be started, and so the
startup will happen in parallel.

This can be worked around by having two separate jobs for nis, one which is
'start on starting autofs (or starting $other_service_that_wants_nis)' and
calls 'exec start wait-for-state WAIT_FOR=nis WAITER="$UPSTART_EVENTS"', and
the other which is 'start on runlevel [2345]' and handles starting nis

This is what I meant by: 

  There are some other behavior quirks to upstart that often result in some
  extra shell scripting in cases like this, which is certainly not optimal

I hope to see this addressed in a future upstream release of upstart.

> I guess that the wanted behavior has to be implemented through some
> sort of "start-nis" task which starts on autofs starting, blocks the
> latter so long as it runs, and stops when nis has started.

Yep, that's exactly it.  Not the most elegant - but certainly not
impossible, which is what I was responding to.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: