Re: upstart: please update to latest upstream version
Steve Langasek <vorlon@debian.org> writes:
> 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.
Which is the problem. Half the time on boot autofs fails to get the maps
from NIS.
> 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
> itself.
>
> 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.
Well, you are totaly cheating and using a dependency based design to
work around the problem.
When was wait-for-state introduced? I don't seem to have this on
Lucid. Another of those growing problems?
>> 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.
Maybe the solution isn't event base or dependency based. Maybe the
right solution is event based and dependency based.
MfG
Goswin
Reply to: