Comment 2 for bug 643289

I have invested some time into analysis of some of the problems the introduction of upstart/mountall created.

Building on Steve Langasek's and Clint Byrum's ideas of introducing fixes in the start-up procedure to make idmapd/gssd and even statd start reliably again, I initially failed due to the limiting sequential (globally blocking) handling of event emission in mountall (see Steve's previous post), which may leave the start-up process with an impossible condition of not having all local file systems mounted, but needing them to actually continue with mounting.

Attached is a fix for this problem (refer to Steve's idea #1). The patch should apply cleanly to mountall 2.20+nmu1, and with only slight context adaption should apply to earlier versions of mountall (such as of lucid).

Note, however, that this fix _alone_ will *not* make statd/idmapd/gssd start cleanly. This is due to the (IMHO weird) handling of multiple instances of the same event category in upstart. The first 'mounting TYPE=nfs4' would trigger the corresponding upstart jobs and block the respective mount in mountall, but subsequent 'mounting TYPE=nfs4' events issued by mountall would not block their mounts in mountall, leaving them to races with statd/idmapd/gssd.
In other words, the first mount in fstab would work ok, others would (probably) still fail.

To fix the latter, I will post adapted job configuration files for statd/idmapd/gssd/rpc_pipefs against nfs-common, and will provide cross reference information here for you to locate them. (The basic idea is to introduce multi-instance versions of the lately introduced statd-mounting job for all of statd/idmapd/gssd, and to take a portmap-wait like approach for rpc_pipefs.)

The fixes have been tested several dozen times on a few machines that represented the most problematic cases of NFS servers and NFS clients that would not even boot up cleanly using stock lucid.