[Bug 643289] Re: idmapd does not starts to work after system reboot
Steve Langasek
steve.langasek at canonical.com
Fri Jul 1 08:39:10 UTC 2011
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
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/643289
Title:
idmapd does not starts to work after system reboot
Status in “mountall” package in Ubuntu:
Triaged
Status in “nfs-utils” package in Ubuntu:
Triaged
Status in “mountall” source package in Lucid:
Triaged
Status in “nfs-utils” source package in Lucid:
Triaged
Bug description:
Binary package hint: nfs-common
I have server which runs Kerberos+LDAP+NFSv4. After installing minimal Ununtu 10.10, I set up Kerberos client and NFSv4. But I've got a problem when restarted computer. After some retries I've noticed that idmapd does not work properly after system restarts but there is a workaround which makes it work:
1. Edit /etc/rc.local and place there following commands
sleep 5
service autofs stop
service idmapd restart
service autofs start
2. Add rc.local to system startup:
update-rc.d rc.local enable
Hope this workaround will help to find out the source of the problem.
It is obvious that something launches in wrong way. But what is that?
Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/643289/+subscriptions
More information about the foundations-bugs
mailing list