Steve Langasek <vor...@debian.org> writes:
> On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
>> > 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.
>
> Ah, it looks to me like this is an out-of-order migration then of the autofs
> init script to an upstart job when the nis package had yet been converted to
> upstart. That's a bug in those packages, plain and simple. Seems to have
> been reported as
> <https://bugs.launchpad.net/ubuntu/+source/nis/+bug/569757>.
>
> I've corrected this now for the upcoming Precise release.
Thanks.
>> Well, you are totaly cheating and using a dependency based design to
>> work around the problem.
>
> Heh. I don't think this is cheating at all; it's always been the intent to
> support this modality in upstart, AFAIK. There are just some cases where
> the currently available built-in semantics fall short of the mark.
>
>> When was wait-for-state introduced? I don't seem to have this on
>> Lucid. Another of those growing problems?
>
> Yes. It was introduced in Ubuntu 11.10.
Can I just copy the wait-for-state job onto a lucid system or does it
need a newer upstart as well?
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/8762ereexe.fsf@frosties.localnet
