On Sun, 2012-02-26 at 17:24 +0100, Goswin von Brederlow wrote: > Steve Langasek <firstname.lastname@example.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 <email@example.com> 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 '. 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. [...] We use autofs and NIS at work, and I found that this was also unreliable on Fedora 16 (using systemd). I would have to restart the autofs service before logging in. A subsequent update seems to have made it reliable again, but I didn't look at how they do this. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway.
Description: This is a digitally signed message part