I agree with Steve's analysis; the NEED_IDMAPD check here is redundant. I have actually considered moving the rpc_pipefs job's contents directly into the idmapd and gssd jobs since the current start condition of rpc_pipefs makes it significantly less useful to have it as a separate job, but haven't gotten to it yet. But that current start condition in natty and above should not have races that allow idmapd to start before rpc_pipefs is mounted.
It may be that backporting the current rpc_pipefs job to lucid, to ensure that we block *both* gssd and idmapd until rpc_pipefs is mounted instead of only blocking the first of the two which tries to start, would solve the problem Leonardo and Steve are having. I haven't done this yet because it's not a complete solution for the issues with idmapd (see comment #1 regarding the changes needed in mountall to go with this), but provided /usr is not a separate filesystem, it may be sufficient. BTW, calling grep, mount, and rpc.idmapd from the script block is definitely wrong, as this job is 'expect fork' and upstart will wind up trying to supervise the first forked process instead of rpc.idmapd. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/643289 Title: idmapd does not starts to work after system reboot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/643289/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
