Because the idmapd upstart job uses a script line instead of directly exec'ing the server, in the case where /usr is a separate partition and not yet mounted at the time the job is started (e.g., because an NFS mount is attempted in parallel to an fsck of /usr), the job will fail to start and get wedged in a 'start/running' state with no associated PID (upstart bug #545673). If we exec the daemon directly, upstart will detect the exec() failure and respawn as needed.
This partially addresses the problems described in bug #643289, and is worth SRUing in its own right even though it doesn't provide a complete solution for all users.
Because the idmapd upstart job uses a script line instead of directly exec'ing the server, in the case where /usr is a separate partition and not yet mounted at the time the job is started (e.g., because an NFS mount is attempted in parallel to an fsck of /usr), the job will fail to start and get wedged in a 'start/running' state with no associated PID (upstart bug #545673). If we exec the daemon directly, upstart will detect the exec() failure and respawn as needed.
This partially addresses the problems described in bug #643289, and is worth SRUing in its own right even though it doesn't provide a complete solution for all users.