Comment 14 for bug 643289

Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 643289] Re: idmapd does not starts to work after system reboot

Excerpts from Steve Atwell's message of Sat Jun 25 01:09:05 UTC 2011:
> In my configuration, /etc/fstab has only local filesystems. NFS
> filesystems are not mounted until later by autofs.
>
> This means that idmapd should be starting on the local-filesystems
> event.
>
> rpc_pipefs has "start on (starting gssd or starting idmapd)". My
> understanding is that rpc_pipefs should run to completion before idmapd
> is allowed to start.
>
> For some reason this dependency insertion based on "starting" isn't
> working. I find that I can make idmapd fail reliably by making the
> rpc_pipefs job take longer. If I insert a sleep 10 into
> /etc/init/rpc_pipefs.conf just before the mount command, idmapd will
> always fail to start, complaining about /var/lib/nfs/rpc_pipefs/nfs just
> as in comment #7 above.

Or's can be tricky for blocking. The first one that gets hit will block,
but not the second one.

Since you have 'start on starting gssd or starting idmapd', the first
one to trigger rpc_pipefs is the only one that gets blocked. gssd
is start on started portmap, which starts on virtual-filesystems and
net-device-up IFACE=lo.

So whats actually happening is rpc_pipefs is only blocking gssd.

What should probably be done is the new 'wait-for-state' job that I
introduced recently should be added to the pre-start of gssd and idmapd..

start wait-for-state WAIT_FOR=rpc_pipefs WAITER=gssd

I recall that ther eis a bug in upstart to track the OR condition problem,
but its bug # escapes me.