Steve Langasek <vor...@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 <vor...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqd1imvj.fsf@frosties.localnet