Summary: | net-fs/nfs-utils-1.1.4-r1: rpc.idmapd doesn't start when DNOTIFY is disabled | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | Network Filesystems <net-fs> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pacho Ramos
![]() Reassigning to net-fs herd. you need to describe the package you're actually using: what version of nfs-utils do you have installed ? rpc.idmapd should make rpc.pipefs run and the later will mount the right dir on /var/lib/nfs/rcp_pipefs/ It's 1.1.4-r1 But behavior is really strange: 1. I editted my fstab for mounting it as nfs4, then, /etc/init.d/nfsmount restart started to fail due rpc.idmapd not being able to be started. 2. Then, I editted fstab agaibn for getting it back to nfs instead of nfs4 but, even with that, /etc/init/nfsmount restart still failled with the same (even after a reboot). 3. I looked to nfsmount init.d file and added two "echo" at end of each: [ ${ret} -eq 10 ] && myneed="${myneed} rpc.gssd" [ ${ret} -eq 20 ] && myneed="${myneed} rpc.idmapd" line for trying to see why rpc.idmapd was being still required to be started (even when I was using old "nfs" again) 4. Just after adding these "echo"s, /etc/init.d/nfsmount restart worked again (?!), as rpc.idmapd is no required again. And even re-editting fstab for using nfs4 again, rpc.idmapd is no longer required to start nfsmount (even when it still fails when manually started and mount.nfs4 fails with a different error) forget about that for now if you start rpc.idmapd manually, does it work ? /etc/init.d/rpc.idmapd start No, I get the same: Mar 8 21:35:35 belkin2 rpc.idmapd[19063]: main: fcntl(/var/lib/nfs/rpc_pipefs//nfs): Invalid argument is rpc.pipefs started ? what does `mount` show ? (In reply to comment #6) > is rpc.pipefs started ? what does `mount` show ? > Seems that not as I get: * Starting idmapd ... [ !! ] mount output: # mount /dev/sda1 on / type reiserfs (rw,noatime,user_xattr,notail) /proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620) /dev/sda5 on /home type reiserfs (rw,noatime,user_xattr,notail) /dev/sda6 on /usr/portage type ext2 (rw,noatime) /dev/sda3 on /mnt/windows type fuseblk (rw,allow_other,blksize=4096) shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) tmpfs on /var/tmp/portage type tmpfs (rw) gvfs-fuse-daemon on /home/pacho/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=pacho) ---- I am now with net-fs/nfs-utils-1.1.5 and I have the same problem Thanks :-) so look in /var/lib/nfs/rpc_pipefs/ to see what all is in there did you enable all the proper nfs4 options in your kernel ? Seems that only empty subdirs are being created: # ls -lR /var/lib/nfs/rpc_pipefs/ /var/lib/nfs/rpc_pipefs/: total 0 dr-xr-xr-x 2 root root 0 mar 10 08:47 lockd dr-xr-xr-x 2 root root 0 mar 10 08:47 mount dr-xr-xr-x 2 root root 0 mar 10 08:47 nfs dr-xr-xr-x 2 root root 0 mar 10 08:47 portmap dr-xr-xr-x 2 root root 0 mar 10 08:47 statd /var/lib/nfs/rpc_pipefs/lockd: total 0 /var/lib/nfs/rpc_pipefs/mount: total 0 /var/lib/nfs/rpc_pipefs/nfs: total 0 /var/lib/nfs/rpc_pipefs/portmap: total 0 /var/lib/nfs/rpc_pipefs/statd: total 0 About kernel config, I have: CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_COMMON=y I can attach full config if you want. Best regards do you have DNOTIFY turned off ? try enabling that in your kernel if you dont (In reply to comment #10) > do you have DNOTIFY turned off ? try enabling that in your kernel if you dont > After turning it on it rpc-idmapd starts: Mar 10 10:39:00 belkin2 rpc.idmapd[8491]: nss_getpwnam: name '0' does not map into domain 'local.domain.edu' Well, I still cannot mount nfs4 shared due: * Mounting NFS filesystems ... mount.nfs4: mounting belkin3:/usr/distfiles failed, reason given by server: No such file or directory [ !! ] but it seems a different problem Thanks a lot for your attention :-) hmm, how best to solve it ... if the message that was logged was updated, would that be enough you think ? Mar 8 15:13:36 belkin2 rpc.idmapd[12140]: main: fcntl(/var/lib/nfs/rpc_pipefs//nfs): Invalid argument (DNOTIFY enabled in kernel?) It would be nice from upstream point of view but, anyway, I think that, if you don't want to inherit linux-info.eclass for using CONFIG_CHECK, maybe adding an elog line with this info would be better. I say this because for seeing "fcntl(/var/lib/nfs/rpc_pipefs//nfs): Invalid argument" I need to manually check /var/log/messages (or check tty12 in my case as I have syslog-ng configured for showing messages on it), because this error is not being shown when simply typing "/etc/init.d/rpc.idmapd start" (at least with current stable baselayout, I don't know if this is shown when using openrc...) I know that, usually, users that will send bug reports will check /var/log/messages first, but maybe some users would still post this problem in forums without checking messages file. This could be prevented if ebuild would stop if DNOTIFY is not in config file or with a elog message (if nonfsv4 USE flag is not set) failures for runtime kernel features are not ok to check in ebuilds. packages can be cross-compiled, built up for binary-only, etc... so checking the kernel is not ok. if the warning was in the init.d, it might be better: # /etc/init.d/rpc.idmapd start * Starting idmapd... * make sure DNOTIFY support is enabled ... [ !! ] * ERROR: rpc.idmapd failed to start http://sources.gentoo.org/net-fs/nfs-utils/files/rpc.idmapd.initd?r1=1.7&r2=1.8 as for the source code, it seems upstream has done this already: if (fcntl(fd, F_NOTIFY, DN_CREATE | DN_DELETE | DN_MODIFY | DN_MULTISHOT) == -1) { xlog_err("main: fcntl(%s): %s", pipefsdir, strerror(errno)); if (errno == EINVAL) xlog_err("main: Possibly no Dnotify support in kernel."); } OK, it's fine :-) Thanks a lot for your attention and the explanation about why I was wrong suggesting checking this in ebuild Regards! |