On Fri, Jul 11, 2008 at 11:19:53PM +0200, Steinar H. Gunderson wrote:
> On Fri, Jul 11, 2008 at 09:48:05PM +0400, Alexandra N. Kossovsky wrote:
> > Feel free to ask me for more info.
>
> OK, this sounds like an upstream bug. I guess you will have more luck
> contacting them; I cannot reproduce this, and I haven't seen any bug reports
> saying the same thing either, so this is pretty much out of my grasp.
No, it looks as upstream feature, with a bug in Debian init scripts.
1. One more experiment: I've unloaded all nfs-related modules and
started nfs-common and nfs-kernel server manually (in this order).
I see in daemon.log:
Jul 14 12:05:45 gondor rpc.statd[3915]: Version 1.1.2 Starting
Jul 14 12:05:45 gondor rpc.idmapd[3935]: libnfsidmap: using domain: oktetlabs.ru
Jul 14 12:05:45 gondor rpc.idmapd[3935]: libnfsidmap: using translation method:
nsswitch
Jul 14 12:05:45 gondor rpc.idmapd[3936]: Expiration time is 600 seconds.
Jul 14 12:05:45 gondor rpc.idmapd[3936]: nfsdopenone: Opening /proc/net/rpc/nfs4
.nametoid/channel failed: errno 2 (No such file or directory)
Jul 14 12:06:38 gondor rpc.idmapd[3936]: New client: 9
Obviously, there is no /proc/net/rpc/nfs4.nametoid, because nfsd is not
loaded. As a result, idmapd does not work for nfsd even when nfsd is
loaded.
2. Let's look into the code nfs-utils-1.1.2/utils/idmapd/idmapd.c:
nfsdopen() tries to open NFSD_DIR/nfs4.idtoname/channel and
NFSD_DIR/nfs4.nametoid/channel , where NFSD_DIR is
/proc/net/rpc/.
If one of these files does not exist, idmapd does not serve as
mapping engine for _this_ direction. /proc/net/rpc/nfs4.nametoid/channel
is created by nfsd module when it is loaded, so idmapd can't open the
file if it is started before nfsd is loaded.
You may call it "upstream bug", but what behaviour do you propose for
idmapd? If one of the files does not exist, it may:
- spin forever, waiting for non-existing file. So, if nfsd is not
compiled at all (or is not loaded at all), idmapd will spin FOREVER.
- ignore the non-existing file and serve in one direction only -- as
it is done.
Really, idmapd re-opens both files if you send SIGHUP, so it is
sufficient to SIGHUP idmapd after nfsd is loaded (i.e. in the end of
/etc/init.d/nfs-kernel-server actions).
3. Let's look into any other Linux distro. I have Fedora Core 8 at hand,
so I'll look into it. FC8 has following nfs-related boot sequence
(runlevel 5):
/etc/rc5.d/S14nfslock
/etc/rc5.d/S18rpcidmapd - start idmapd
/etc/rc5.d/S19rpcgssd
/etc/rc5.d/S60nfs - start rpcsvcgssd & nfsd
In /etc/rc.d/init.d/nfs, I see following as part of "start" action:
# Let rpc.idmapd know that rpc.mountd just started
[ -x /usr/sbin/rpc.idmapd ] && /sbin/service rpcidmapd condstart
The only thing I do not understand is why you cannot reproduce it. Have
you tried?
Regards,
Alexandra.
--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)
Phones: +7(921)956-42-86(mobile) +7(812)783-21-91(office)
e-mail: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
