Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
Hello. I am using nfsv4 in etch, and experienced the same problem. The workaround you say solves it, but I am afraid an update overwrites nfs-common, and then the workaround is lost. So, could it be possible that this bug get also fixed in etch? Thank you very much. __ Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
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]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Mon, Jul 14, 2008 at 12:46:19PM +0400, Alexandra N. Kossovsky wrote: The only thing I do not understand is why you cannot reproduce it. Have you tried? My options for actually testing this is rather limited -- I only run NFSv4 one place, and it's in production. The limited testing I am able to do there was obviously not enough. :-) Still, it's weird that I haven't seen this, for your analysis looks very thorough (thanks!). Perhaps idmapd was HUPed for some unknown reason in my case. The reason I'm a bit skeptical to loading nfsd.ko unconditionally in nfs-common, since every time I do such things people come complaining to me that something broke in their setup with no nfsd modules or whatnot. The alternative is trying to send the HUP to idmapd, which is a pretty slippery slope (I gave up trying to track these daemon's pids a long time ago). I'll do as you suggested -- load nfsd.ko before idmapd -- and then I hope people won't complain too loudly. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Thu, Jul 10, 2008 at 08:17:21PM +0200, Steinar H. Gunderson wrote: Well, I guess the big question is: What happens on startup -- does it try to start idmapd at all? Yes, obviously. I see this start in the logs and, additionally, idmapd works for for _client_ nfs4 (i.e. volumes mounted from other servers on this machine have correct owners). And what does your /etc/default/nfs-kernel-server look like? # If you do not set values for the NEED_ options, they will be attempted # autodetected; this should be sufficient for most people. Valid alternatives # for the NEED_ options are yes and no. # Do you want to start the statd daemon? It is not needed for NFSv4. NEED_STATD= # Options for rpc.statd. # Should rpc.statd listen on a specific port? This is especially useful # when you have a port-based firewall. To use a fixed port, set this # this variable to a statd argument like: --port 4000 --outgoing-port 4001. # For more information, see rpc.statd(8) or http://wiki.debian.org/?SecuringNFS STATDOPTS= # Do you want to start the idmapd daemon? It is only needed for NFSv4. NEED_IDMAPD=yes # Do you want to start the gssd daemon? It is required for Kerberos mounts. NEED_GSSD=yes #RPCGSSDOPTS=-r -v -- 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]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Thu, Jul 10, 2008 at 08:17:21PM +0200, Steinar H. Gunderson wrote: On Thu, Jul 10, 2008 at 07:15:45PM +0400, Alexandra N. Kossovsky wrote: The same problem exists with etch; I've just added the 2 lines above to the end of /etc/init.d/nfs-kernel-server. However, I'd like to see the problem really fixed in lenny. I've found better workaround: modprobe nfsd in /etc/init.d/nfs-common before start of idmapd solves the problem. Also, the problem is solved by adding nfsd to /etc/modules. I have not try this workaround with etch -- only with lenny, but I guess it should work for etch as well. -- 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]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Fri, Jul 11, 2008 at 01:41:35PM +0400, Alexandra N. Kossovsky wrote: I've found better workaround: modprobe nfsd in /etc/init.d/nfs-common before start of idmapd solves the problem. Also, the problem is solved by adding nfsd to /etc/modules. I have not try this workaround with etch -- only with lenny, but I guess it should work for etch as well. One of the first things that happen in /etc/init.d/nfs-kernel-server is a modprobe of nfsd... Do you have an /etc/exports at all? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Fri, Jul 11, 2008 at 02:52:32PM +0200, Steinar H. Gunderson wrote: On Fri, Jul 11, 2008 at 01:41:35PM +0400, Alexandra N. Kossovsky wrote: I've found better workaround: modprobe nfsd in /etc/init.d/nfs-common before start of idmapd solves the problem. Also, the problem is solved by adding nfsd to /etc/modules. I have not try this workaround with etch -- only with lenny, but I guess it should work for etch as well. One of the first things that happen in /etc/init.d/nfs-kernel-server is a modprobe of nfsd... Do you have an /etc/exports at all? Yes I do. /etc/init.d/nfs-common is started at /etc/rcS.d/S44nfs-common, while nfs-kernel-server loads nfsd too late, at /etc/rc2.d/S20nfs-kernel-server. No, I've not changes init sequence manually -- it matches with /var/lib/dpkg/info/nfs-common.postinst. -- 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]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Fri, Jul 11, 2008 at 06:53:55PM +0400, Alexandra N. Kossovsky wrote: One of the first things that happen in /etc/init.d/nfs-kernel-server is a modprobe of nfsd... Do you have an /etc/exports at all? Yes I do. /etc/init.d/nfs-common is started at /etc/rcS.d/S44nfs-common, while nfs-kernel-server loads nfsd too late, at /etc/rc2.d/S20nfs-kernel-server. No, I've not changes init sequence manually -- it matches with /var/lib/dpkg/info/nfs-common.postinst. I think I asked you this already, without a reply: What does idmapd say at startup? It _should_ be loaded, and it should not depend on nfsd.ko. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Fri, Jul 11, 2008 at 06:37:01PM +0200, Steinar H. Gunderson wrote: On Fri, Jul 11, 2008 at 06:53:55PM +0400, Alexandra N. Kossovsky wrote: One of the first things that happen in /etc/init.d/nfs-kernel-server is a modprobe of nfsd... Do you have an /etc/exports at all? Yes I do. /etc/init.d/nfs-common is started at /etc/rcS.d/S44nfs-common, while nfs-kernel-server loads nfsd too late, at /etc/rc2.d/S20nfs-kernel-server. No, I've not changes init sequence manually -- it matches with /var/lib/dpkg/info/nfs-common.postinst. I think I asked you this already, without a reply: What does idmapd say at startup? It _should_ be loaded, and it should not depend on nfsd.ko. Previously, you've asked if it starts. And I've answered that yes, it starts. And even works for client nsf4. Here are logs: /var/log/boot: Fri Jul 11 21:22:48 2008: Starting portmap daemon Fri Jul 11 21:22:48 2008: Starting NFS common utilities: statd idmapdrpc.idmapd: libnfsidmap: using domain: oktetlabs.ru Fri Jul 11 21:22:48 2008: Fri Jul 11 21:22:48 2008: rpc.idmapd: libnfsidmap: using translation method: nsswitch Fri Jul 11 21:22:48 2008: Fri Jul 11 21:22:48 2008: gssd. Fri Jul 11 21:22:49 2008: Starting portmap daemon...Already running.. Fri Jul 11 21:22:49 2008: Starting NFS common utilities: statd idmapd gssd. Fri Jul 11 21:22:49 2008: Loading the saved-state of the serial devices... ... Fri Jul 11 21:22:52 2008: INIT: Entering runlevel: 2 ... Fri Jul 11 21:22:59 2008: Starting network benchmark server. Fri Jul 11 21:22:59 2008: Starting NFS common utilities: statd idmapd gssd. Fri Jul 11 21:22:59 2008: Exporting directories for NFS kernel daemon Fri Jul 11 21:22:59 2008: Starting NFS kernel daemon: nfsd svcgssd mountd. Fri Jul 11 21:22:59 2008: Starting Name Service Cache Daemon: nscd. /var/log/daemon.log: nothing idmapd-related earlier Jul 11 21:23:55 gondor rpc.idmapd[2453]: nss_getpwnam: name 'sasha_at_oktetlabs.ru' domain 'oktetlabs.ru': resulting localname 'sasha' Jul 11 21:23:55 gondor rpc.idmapd[2453]: Client 0: (user) name sasha_at_oktetlabs.ru - id 1000 Jul 11 21:23:55 gondor rpc.idmapd[2453]: nss_getpwnam: name 'arybchik_at_oktetlabs.ru' domain 'oktetlabs.ru': resulting localname 'arybchik' Jul 11 21:23:55 gondor rpc.idmapd[2453]: Client 0: (user) name arybchik_at_oktetlabs.ru - id 1004 Jul 11 21:23:55 gondor rpc.idmapd[2453]: nss_getpwnam: name 'helen_at_oktetlabs.ru' domain 'oktetlabs.ru': resulting localname 'helen' Jul 11 21:23:55 gondor rpc.idmapd[2453]: Client 0: (user) name helen_at_oktetlabs.ru - id 1003 ... Jul 11 21:25:11 gondor rpc.idmapd[2453]: New client: a Jul 11 21:25:11 gondor rpc.idmapd[2453]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnta/idmap Jul 11 21:25:11 gondor rpc.idmapd[2453]: New client: b Jul 11 21:25:11 gondor rpc.idmapd[2453]: nss_getpwnam: name 'root_at_oktetlabs.ru' domain 'oktetlabs.ru': resulting localname 'root' Jul 11 21:25:11 gondor rpc.idmapd[2453]: Client a: (user) name root_at_oktetlabs.ru - id 0 Jul 11 21:25:11 gondor rpc.idmapd[2453]: Client a: (group) name root_at_oktetlabs.ru - id 0 Jul 11 21:25:11 gondor rpc.idmapd[2453]: nss_getpwnam: name 'artem_at_oktetlabs.ru' domain 'oktetlabs.ru': resulting localname 'artem' Jul 11 21:25:11 gondor rpc.idmapd[2453]: Client a: (user) name artem_at_oktetlabs.ru - id 1031 Jul 11 21:25:11 gondor rpc.idmapd[2453]: Client a: (group) name oktetlabs_at_oktetlabs.ru - id 1000 Jul 11 21:25:12 gondor rpc.idmapd[2453]: Client a: (group) name plugdev_at_oktetlabs.ru - id 46 (I've replaced '@' by '_at_') /var/log/messages: nothing nfs-related earlier Jul 11 21:22:59 gondor kernel: Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). Jul 11 21:22:59 gondor kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 11 21:22:59 gondor kernel: NFSD: starting 90-second grace period Jul 11 21:23:00 gondor /usr/sbin/gpm[3536]: *** info [mice.c(2059)]: Jul 11 21:23:00 gondor /usr/sbin/gpm[3536]: Detected EXPS/2 protocol mouse. Jul 11 21:23:07 gondor autossh[3828]: starting ssh (count 1) Jul 11 21:23:07 gondor autossh[3828]: ssh child pid is 3829 Jul 11 21:23:11 gondor kernel: [drm] Initialized drm 1.1.0 20060810 Jul 11 21:23:11 gondor kernel: ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 Jul 11 21:23:11 gondor kernel: [drm] Initialized radeon 1.28.0 20060524 on minor 0 Jul 11 21:23:13 gondor kernel: [drm] Setting GART location based on new memory map Jul 11 21:23:13 gondor kernel: [drm] Loading R300 Microcode Jul 11 21:23:13 gondor kernel: [drm] writeback test succeeded in 1 usecs Jul 11 21:24:01 gondor kernel: nfsd: nfsv4 idmapping failing: has idmapd not been started? When I add nfsd to /etc/modules, I see absolutely the same messages on boot. However, with nfsd in /etc/modules, idmapd really works for both nfs client and nfsd. It looks a bit strange for me that I do not see any boot-time idmapd messages in
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
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. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
Package: nfs-common Version: 1:1.1.2-4 Severity: important I have a lenny machine which is at the same time nfs4 server and nfs4 client. All nfs4 servers/clients use nsswitch translation method. After reboot, I see mounted nsf4 files with correct owners; however, my clients see my exported files as nobody:nogroup. At the same time, my server complains: Jul 10 18:59:47 gondor kernel: nfsd: nfsv4 idmapping failing: has idmapd not been started? Restart of idmapd solves the problem: start-stop-daemon --stop --oknodo --quiet --name rpc.idmapd start-stop-daemon --start --oknodo --quiet --exec /usr/sbin/rpc.idmapd The same problem exists with etch; I've just added the 2 lines above to the end of /etc/init.d/nfs-kernel-server. However, I'd like to see the problem really fixed in lenny. If it matters, I use libnss-ldap. I've checked that nss is able to resolve user names before idmapd is stared by inserting some echo in init scripts. Feel free to ask me if you need any more details. Thank you for your work. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nfs-common depends on: ii adduser 3.108 add and remove users and groups ii initscripts 2.86.ds1-59Scripts for initializing and shutt ii libc6 2.7-10 GNU C Library: Shared libraries ii libcomerr21.40.11-1 common error description library ii libevent1 1.3e-3 An asynchronous event notification ii libgssglue1 0.1-2 mechanism-switch gssapi library ii libkrb53 1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries ii libnfsidmap2 0.20-1 An nfs idmapping library ii librpcsecgss3 0.18-1 allows secure rpc communication us ii libwrap0 7.6.q-15 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip ii netbase 4.32 Basic TCP/IP networking system ii portmap 6.0-6 RPC port mapper ii ucf 3.007 Update Configuration File: preserv nfs-common recommends no packages. -- debconf-show failed -- Regards, Sasha. Alexandra N. Kossovsky, software engineer. e-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490181: nfsd: nfsv4 idmapping failing: has idmapd not been started?
On Thu, Jul 10, 2008 at 07:15:45PM +0400, Alexandra N. Kossovsky wrote: The same problem exists with etch; I've just added the 2 lines above to the end of /etc/init.d/nfs-kernel-server. However, I'd like to see the problem really fixed in lenny. Well, I guess the big question is: What happens on startup -- does it try to start idmapd at all? And what does your /etc/default/nfs-kernel-server look like? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
