* [basic] nfsd failing to start
@ 2009-01-11 21:41 Harry P
[not found] ` <87zlhxy102.fsf-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 9+ messages in thread
From: Harry P @ 2009-01-11 21:41 UTC (permalink / raw)
To: linux-nfs
NOTE: This is a repost of a message posted on gentoo.user list
I've apparently forgotten whatever little I may have known about
setting up nfs from having used it long ago.
I found a brief help page on google that I used to get this far along
at:
http://linux-bsd-sharing.blogspot.com/2008/09/howto-setup-nfs-server-on-gentoo.html
Its very brief and has no debugging info.
Also I see nothing about debugging in /etc/conf.d/nfs either.
After setting all nfs related kernel items and booting the kernel.
(The setting are inlined toward the end of this message)
Checking that mods appears to be installed and running. Making sure
portmapper is running.
Then when I try to start nfsd service it fails, producing these
messages in sysklogd:
Jan [...] nfsd[29077]: nfssvc: Protocol not supported
Jan [...' : RPC: failed to contact local rpcbind server (errno 5).
Only one of the nfssvc lines appear but the RPC line appears several
times.
I got the impression from google that nfssvc was related to nfs4 so
may not mean too much ... but then I'm really not sure what it might
mean.
I don't really know what info would be helpfull but have included
output from emerge, rpcinfo, lsmod and related kernel settings:
Installed nfs related pkgs
[...]
Sat Jan 10 18:30:11 2009 >>> net-libs/libnfsidmap-0.21-r1
Sat Jan 10 18:30:30 2009 >>> net-nds/portmap-6.0
Sat Jan 10 18:31:20 2009 >>> dev-libs/libevent-1.4.9
Sat Jan 10 18:32:39 2009 >>> net-fs/nfs-utils-1.1.4
===== * ===== * ===== * =====
kernel:
# grep 'NFS\|RPC' .config
# CONFIG_AF_RXRPC is not set
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_REGISTER_V4=y
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
===== * ===== * ===== * =====
# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 34971 status
100024 1 tcp 43460 status
100005 1 udp 34365 mountd
100005 1 tcp 44349 mountd
100005 2 udp 34365 mountd
100005 2 tcp 44349 mountd
100005 3 udp 34365 mountd
100005 3 tcp 44349 mountd
===== * ===== * ===== * =====
lsmod
Module Size Used by
nfs 206772 0
nfsd 185008 9
lockd 55160 2 nfs,nfsd
nfs_acl 2688 2 nfs,nfsd
auth_rpcgss 28548 1 nfsd
sunrpc 144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss
exportfs 3456 1 nfsd
fuse 42268 0
usbhid 13588 0
usbmouse 3712 0
usbkbd 4992 0
floppy 45348 0
pcspkr 2176 0
i2c_i801 7952 0
r8169 26500 0
i2c_core 17680 1 i2c_i801
mii 4224 1 r8169
snd_intel8x0 25500 0
snd_ac97_codec 88352 1 snd_intel8x0
ehci_hcd 28684 0
uhci_hcd 18444 0
ac97_bus 1536 1 snd_ac97_codec
snd_pcm 48008 2 snd_intel8x0,snd_ac97_codec
snd_timer 15364 1 snd_pcm
snd 34788 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
usbcore 104760 6 usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd
snd_page_alloc 7304 2 snd_intel8x0,snd_pcm
intel_agp 22588 1
agpgart 25520 1 intel_agp
button 5904 0
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
[not found] ` <87zlhxy102.fsf-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
@ 2009-01-12 17:24 ` J. Bruce Fields
2009-01-12 21:09 ` Harry P
2009-01-12 22:14 ` Chuck Lever
0 siblings, 2 replies; 9+ messages in thread
From: J. Bruce Fields @ 2009-01-12 17:24 UTC (permalink / raw)
To: Harry P; +Cc: linux-nfs, Chuck Lever
On Sun, Jan 11, 2009 at 03:41:01PM -0600, Harry P wrote:
> NOTE: This is a repost of a message posted on gentoo.user list
>
> I've apparently forgotten whatever little I may have known about
> setting up nfs from having used it long ago.
>
> I found a brief help page on google that I used to get this far along
> at:
> http://linux-bsd-sharing.blogspot.com/2008/09/howto-setup-nfs-server-on-gentoo.html
>
> Its very brief and has no debugging info.
>
> Also I see nothing about debugging in /etc/conf.d/nfs either.
>
> After setting all nfs related kernel items and booting the kernel.
> (The setting are inlined toward the end of this message)
> Checking that mods appears to be installed and running. Making sure
> portmapper is running.
>
> Then when I try to start nfsd service it fails, producing these
> messages in sysklogd:
>
> Jan [...] nfsd[29077]: nfssvc: Protocol not supported
> Jan [...' : RPC: failed to contact local rpcbind server (errno 5).
Hm, maybe it's the portmap version:
>
> Only one of the nfssvc lines appear but the RPC line appears several
> times.
>
> I got the impression from google that nfssvc was related to nfs4 so
> may not mean too much ... but then I'm really not sure what it might
> mean.
>
> I don't really know what info would be helpfull but have included
> output from emerge, rpcinfo, lsmod and related kernel settings:
>
> Installed nfs related pkgs
> [...]
> Sat Jan 10 18:30:11 2009 >>> net-libs/libnfsidmap-0.21-r1
> Sat Jan 10 18:30:30 2009 >>> net-nds/portmap-6.0
> Sat Jan 10 18:31:20 2009 >>> dev-libs/libevent-1.4.9
> Sat Jan 10 18:32:39 2009 >>> net-fs/nfs-utils-1.1.4
>
> ===== * ===== * ===== * =====
>
> kernel:
> # grep 'NFS\|RPC' .config
>
> # CONFIG_AF_RXRPC is not set
> CONFIG_NFS_FS=m
> CONFIG_NFS_V3=y
> CONFIG_NFS_V3_ACL=y
> CONFIG_NFS_V4=y
> CONFIG_NFSD=m
> CONFIG_NFSD_V2_ACL=y
> CONFIG_NFSD_V3=y
> CONFIG_NFSD_V3_ACL=y
> CONFIG_NFSD_V4=y
> CONFIG_NFS_ACL_SUPPORT=m
> CONFIG_NFS_COMMON=y
> CONFIG_SUNRPC=m
> CONFIG_SUNRPC_GSS=m
> CONFIG_SUNRPC_REGISTER_V4=y
>From the config help test: "If you enable this option, you must run a
portmapper daemon that supports rpcbind protocol version 4."
Chuck, what's the minimum userland required to support this?
--b.
> CONFIG_RPCSEC_GSS_KRB5=m
> # CONFIG_RPCSEC_GSS_SPKM3 is not set
>
> ===== * ===== * ===== * =====
>
> # rpcinfo -p localhost
> program vers proto port
> 100000 2 tcp 111 portmapper
> 100000 2 udp 111 portmapper
> 100024 1 udp 34971 status
> 100024 1 tcp 43460 status
> 100005 1 udp 34365 mountd
> 100005 1 tcp 44349 mountd
> 100005 2 udp 34365 mountd
> 100005 2 tcp 44349 mountd
> 100005 3 udp 34365 mountd
> 100005 3 tcp 44349 mountd
>
> ===== * ===== * ===== * =====
>
> lsmod
>
> Module Size Used by
> nfs 206772 0
> nfsd 185008 9
> lockd 55160 2 nfs,nfsd
> nfs_acl 2688 2 nfs,nfsd
> auth_rpcgss 28548 1 nfsd
> sunrpc 144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss
> exportfs 3456 1 nfsd
> fuse 42268 0
> usbhid 13588 0
> usbmouse 3712 0
> usbkbd 4992 0
> floppy 45348 0
> pcspkr 2176 0
> i2c_i801 7952 0
> r8169 26500 0
> i2c_core 17680 1 i2c_i801
> mii 4224 1 r8169
> snd_intel8x0 25500 0
> snd_ac97_codec 88352 1 snd_intel8x0
> ehci_hcd 28684 0
> uhci_hcd 18444 0
> ac97_bus 1536 1 snd_ac97_codec
> snd_pcm 48008 2 snd_intel8x0,snd_ac97_codec
> snd_timer 15364 1 snd_pcm
> snd 34788 4 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
> usbcore 104760 6 usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd
> snd_page_alloc 7304 2 snd_intel8x0,snd_pcm
> intel_agp 22588 1
> agpgart 25520 1 intel_agp
> button 5904 0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 17:24 ` J. Bruce Fields
@ 2009-01-12 21:09 ` Harry P
2009-01-12 21:29 ` Chuck Lever
2009-01-12 22:14 ` Chuck Lever
1 sibling, 1 reply; 9+ messages in thread
From: Harry P @ 2009-01-12 21:09 UTC (permalink / raw)
To: linux-nfs
"J. Bruce Fields" <bfields@fieldses.org>
writes:
>> CONFIG_NFS_FS=m
>> CONFIG_NFS_V3=y
>> CONFIG_NFS_V3_ACL=y
>> CONFIG_NFS_V4=y
>> CONFIG_NFSD=m
>> CONFIG_NFSD_V2_ACL=y
>> CONFIG_NFSD_V3=y
>> CONFIG_NFSD_V3_ACL=y
>> CONFIG_NFSD_V4=y
>> CONFIG_NFS_ACL_SUPPORT=m
>> CONFIG_NFS_COMMON=y
>> CONFIG_SUNRPC=m
>> CONFIG_SUNRPC_GSS=m
>> CONFIG_SUNRPC_REGISTER_V4=y
>
> From the config help test: "If you enable this option, you must run a
> portmapper daemon that supports rpcbind protocol version 4."
Thanks, with your clue I commented all nfs and SunRPC 4 related lines
recompiled and rebooted... started up with no problems.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 21:09 ` Harry P
@ 2009-01-12 21:29 ` Chuck Lever
2009-01-12 22:00 ` J. Bruce Fields
0 siblings, 1 reply; 9+ messages in thread
From: Chuck Lever @ 2009-01-12 21:29 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
On Jan 12, 2009, at 4:09 PM, Harry P wrote:
> "J. Bruce Fields" <bfields@fieldses.org>
> writes:
>
>>> CONFIG_NFS_FS=m
>>> CONFIG_NFS_V3=y
>>> CONFIG_NFS_V3_ACL=y
>>> CONFIG_NFS_V4=y
>>> CONFIG_NFSD=m
>>> CONFIG_NFSD_V2_ACL=y
>>> CONFIG_NFSD_V3=y
>>> CONFIG_NFSD_V3_ACL=y
>>> CONFIG_NFSD_V4=y
>>> CONFIG_NFS_ACL_SUPPORT=m
>>> CONFIG_NFS_COMMON=y
>>> CONFIG_SUNRPC=m
>>> CONFIG_SUNRPC_GSS=m
>>> CONFIG_SUNRPC_REGISTER_V4=y
>>
>> From the config help test: "If you enable this option, you must run a
>> portmapper daemon that supports rpcbind protocol version 4."
>
> Thanks, with your clue I commented all nfs and SunRPC 4 related lines
> recompiled and rebooted... started up with no problems.
Clearly, setting the Kconfig default to N is not enough to prevent
this problem. I don't understand why this option is getting enabled
without any other intervention on the part of kernel builders. Maybe
we need to update arch/defconfig?
It's on my immediate to-do list to see if the compile-time and run-
time behavior in this area can be improved.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 21:29 ` Chuck Lever
@ 2009-01-12 22:00 ` J. Bruce Fields
0 siblings, 0 replies; 9+ messages in thread
From: J. Bruce Fields @ 2009-01-12 22:00 UTC (permalink / raw)
To: Chuck Lever; +Cc: linux-nfs
On Mon, Jan 12, 2009 at 04:29:48PM -0500, Chuck Lever wrote:
> On Jan 12, 2009, at 4:09 PM, Harry P wrote:
>> "J. Bruce Fields" <bfields@fieldses.org>
>> writes:
>>
>>>> CONFIG_NFS_FS=m
>>>> CONFIG_NFS_V3=y
>>>> CONFIG_NFS_V3_ACL=y
>>>> CONFIG_NFS_V4=y
>>>> CONFIG_NFSD=m
>>>> CONFIG_NFSD_V2_ACL=y
>>>> CONFIG_NFSD_V3=y
>>>> CONFIG_NFSD_V3_ACL=y
>>>> CONFIG_NFSD_V4=y
>>>> CONFIG_NFS_ACL_SUPPORT=m
>>>> CONFIG_NFS_COMMON=y
>>>> CONFIG_SUNRPC=m
>>>> CONFIG_SUNRPC_GSS=m
>>>> CONFIG_SUNRPC_REGISTER_V4=y
>>>
>>> From the config help test: "If you enable this option, you must run a
>>> portmapper daemon that supports rpcbind protocol version 4."
>>
>> Thanks, with your clue I commented all nfs and SunRPC 4 related lines
>> recompiled and rebooted... started up with no problems.
>
> Clearly, setting the Kconfig default to N is not enough to prevent this
> problem. I don't understand why this option is getting enabled without
> any other intervention on the part of kernel builders. Maybe we need to
> update arch/defconfig?
>
> It's on my immediate to-do list to see if the compile-time and run-time
> behavior in this area can be improved.
I'd certainly be happiest if we could just fall back on the earlier
rpcbind protocol version at runtime.
--b.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 17:24 ` J. Bruce Fields
2009-01-12 21:09 ` Harry P
@ 2009-01-12 22:14 ` Chuck Lever
2009-01-12 22:29 ` J. Bruce Fields
1 sibling, 1 reply; 9+ messages in thread
From: Chuck Lever @ 2009-01-12 22:14 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Harry P, linux-nfs
On Jan 12, 2009, at 12:24 PM, J. Bruce Fields wrote:
> On Sun, Jan 11, 2009 at 03:41:01PM -0600, Harry P wrote:
>> NOTE: This is a repost of a message posted on gentoo.user list
>>
>> I've apparently forgotten whatever little I may have known about
>> setting up nfs from having used it long ago.
>>
>> I found a brief help page on google that I used to get this far along
>> at:
>> http://linux-bsd-sharing.blogspot.com/2008/09/howto-setup-nfs-server-on-gentoo.html
>>
>> Its very brief and has no debugging info.
>>
>> Also I see nothing about debugging in /etc/conf.d/nfs either.
>>
>> After setting all nfs related kernel items and booting the kernel.
>> (The setting are inlined toward the end of this message)
>> Checking that mods appears to be installed and running. Making sure
>> portmapper is running.
>>
>> Then when I try to start nfsd service it fails, producing these
>> messages in sysklogd:
>>
>> Jan [...] nfsd[29077]: nfssvc: Protocol not supported
>> Jan [...' : RPC: failed to contact local rpcbind server (errno 5).
>
> Hm, maybe it's the portmap version:
>
>>
>> Only one of the nfssvc lines appear but the RPC line appears several
>> times.
>>
>> I got the impression from google that nfssvc was related to nfs4 so
>> may not mean too much ... but then I'm really not sure what it might
>> mean.
>>
>> I don't really know what info would be helpfull but have included
>> output from emerge, rpcinfo, lsmod and related kernel settings:
>>
>> Installed nfs related pkgs
>> [...]
>> Sat Jan 10 18:30:11 2009 >>> net-libs/libnfsidmap-0.21-r1
>> Sat Jan 10 18:30:30 2009 >>> net-nds/portmap-6.0
>> Sat Jan 10 18:31:20 2009 >>> dev-libs/libevent-1.4.9
>> Sat Jan 10 18:32:39 2009 >>> net-fs/nfs-utils-1.1.4
>>
>> ===== * ===== * ===== * =====
>>
>> kernel:
>> # grep 'NFS\|RPC' .config
>>
>> # CONFIG_AF_RXRPC is not set
>> CONFIG_NFS_FS=m
>> CONFIG_NFS_V3=y
>> CONFIG_NFS_V3_ACL=y
>> CONFIG_NFS_V4=y
>> CONFIG_NFSD=m
>> CONFIG_NFSD_V2_ACL=y
>> CONFIG_NFSD_V3=y
>> CONFIG_NFSD_V3_ACL=y
>> CONFIG_NFSD_V4=y
>> CONFIG_NFS_ACL_SUPPORT=m
>> CONFIG_NFS_COMMON=y
>> CONFIG_SUNRPC=m
>> CONFIG_SUNRPC_GSS=m
>> CONFIG_SUNRPC_REGISTER_V4=y
>
> From the config help test: "If you enable this option, you must run a
> portmapper daemon that supports rpcbind protocol version 4."
>
> Chuck, what's the minimum userland required to support this?
User land must be running a portmapper that supports rpcbind protocol
version 4. Currently Linux's portmapper does not, which is why the
setting defaults to N. Recent Fedora distributions have replaced the
portmap daemon with a port of Sun's rpcbind daemon, which does support
rpcbind version 4. But most other distributions still use portmap.
I was hoping not to clutter svc_register() with logic to determine
which is running, since it will add complexity with little value. And
eventually (or, soon, hopefully) everyone will run the rpcbind port,
and that logic won't be needed at all.
In addition, rpcbind/libtirpc are still not entirely stable (API/ABI-
wise) so it may be better to leave this as a hard compile-time switch
until distributions are comfortable replacing portmap with rpcbind.
> --b.
>
>> CONFIG_RPCSEC_GSS_KRB5=m
>> # CONFIG_RPCSEC_GSS_SPKM3 is not set
>>
>> ===== * ===== * ===== * =====
>>
>> # rpcinfo -p localhost
>> program vers proto port
>> 100000 2 tcp 111 portmapper
>> 100000 2 udp 111 portmapper
>> 100024 1 udp 34971 status
>> 100024 1 tcp 43460 status
>> 100005 1 udp 34365 mountd
>> 100005 1 tcp 44349 mountd
>> 100005 2 udp 34365 mountd
>> 100005 2 tcp 44349 mountd
>> 100005 3 udp 34365 mountd
>> 100005 3 tcp 44349 mountd
>>
>> ===== * ===== * ===== * =====
>>
>> lsmod
>>
>> Module Size Used by
>> nfs 206772 0
>> nfsd 185008 9
>> lockd 55160 2 nfs,nfsd
>> nfs_acl 2688 2 nfs,nfsd
>> auth_rpcgss 28548 1 nfsd
>> sunrpc 144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss
>> exportfs 3456 1 nfsd
>> fuse 42268 0
>> usbhid 13588 0
>> usbmouse 3712 0
>> usbkbd 4992 0
>> floppy 45348 0
>> pcspkr 2176 0
>> i2c_i801 7952 0
>> r8169 26500 0
>> i2c_core 17680 1 i2c_i801
>> mii 4224 1 r8169
>> snd_intel8x0 25500 0
>> snd_ac97_codec 88352 1 snd_intel8x0
>> ehci_hcd 28684 0
>> uhci_hcd 18444 0
>> ac97_bus 1536 1 snd_ac97_codec
>> snd_pcm 48008 2 snd_intel8x0,snd_ac97_codec
>> snd_timer 15364 1 snd_pcm
>> snd 34788 4
>> snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
>> usbcore 104760 6
>> usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd
>> snd_page_alloc 7304 2 snd_intel8x0,snd_pcm
>> intel_agp 22588 1
>> agpgart 25520 1 intel_agp
>> button 5904 0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-
>> nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 22:14 ` Chuck Lever
@ 2009-01-12 22:29 ` J. Bruce Fields
2009-01-12 23:04 ` Chuck Lever
0 siblings, 1 reply; 9+ messages in thread
From: J. Bruce Fields @ 2009-01-12 22:29 UTC (permalink / raw)
To: Chuck Lever; +Cc: Harry P, linux-nfs
On Mon, Jan 12, 2009 at 05:14:15PM -0500, Chuck Lever wrote:
> User land must be running a portmapper that supports rpcbind protocol
> version 4. Currently Linux's portmapper does not, which is why the
> setting defaults to N. Recent Fedora distributions have replaced the
> portmap daemon with a port of Sun's rpcbind daemon, which does support
> rpcbind version 4. But most other distributions still use portmap.
>
> I was hoping not to clutter svc_register() with logic to determine which
> is running, since it will add complexity with little value. And
> eventually (or, soon, hopefully) everyone will run the rpcbind port, and
> that logic won't be needed at all.
Other kernel developers and kernel testers are particularly valuable
kernel users (by which I mean, valuable to us, since they do useful work
for us) who often use new kernels on old distributions.
> In addition, rpcbind/libtirpc are still not entirely stable (API/ABI-
> wise) so it may be better to leave this as a hard compile-time switch
> until distributions are comfortable replacing portmap with rpcbind.
Making it easy to switch between portmap and (newer) rpcbind daemons
might make it easier to test and debug the newer code.
None of this is in contradiction to what you've said--it's a
tradeoff--but on balance I'd prefer the additional svc_register() logic.
--b.
>
>> --b.
>>
>>> CONFIG_RPCSEC_GSS_KRB5=m
>>> # CONFIG_RPCSEC_GSS_SPKM3 is not set
>>>
>>> ===== * ===== * ===== * =====
>>>
>>> # rpcinfo -p localhost
>>> program vers proto port
>>> 100000 2 tcp 111 portmapper
>>> 100000 2 udp 111 portmapper
>>> 100024 1 udp 34971 status
>>> 100024 1 tcp 43460 status
>>> 100005 1 udp 34365 mountd
>>> 100005 1 tcp 44349 mountd
>>> 100005 2 udp 34365 mountd
>>> 100005 2 tcp 44349 mountd
>>> 100005 3 udp 34365 mountd
>>> 100005 3 tcp 44349 mountd
>>>
>>> ===== * ===== * ===== * =====
>>>
>>> lsmod
>>>
>>> Module Size Used by
>>> nfs 206772 0
>>> nfsd 185008 9
>>> lockd 55160 2 nfs,nfsd
>>> nfs_acl 2688 2 nfs,nfsd
>>> auth_rpcgss 28548 1 nfsd
>>> sunrpc 144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss
>>> exportfs 3456 1 nfsd
>>> fuse 42268 0
>>> usbhid 13588 0
>>> usbmouse 3712 0
>>> usbkbd 4992 0
>>> floppy 45348 0
>>> pcspkr 2176 0
>>> i2c_i801 7952 0
>>> r8169 26500 0
>>> i2c_core 17680 1 i2c_i801
>>> mii 4224 1 r8169
>>> snd_intel8x0 25500 0
>>> snd_ac97_codec 88352 1 snd_intel8x0
>>> ehci_hcd 28684 0
>>> uhci_hcd 18444 0
>>> ac97_bus 1536 1 snd_ac97_codec
>>> snd_pcm 48008 2 snd_intel8x0,snd_ac97_codec
>>> snd_timer 15364 1 snd_pcm
>>> snd 34788 4
>>> snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
>>> usbcore 104760 6
>>> usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd
>>> snd_page_alloc 7304 2 snd_intel8x0,snd_pcm
>>> intel_agp 22588 1
>>> agpgart 25520 1 intel_agp
>>> button 5904 0
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 22:29 ` J. Bruce Fields
@ 2009-01-12 23:04 ` Chuck Lever
2009-01-13 3:34 ` J. Bruce Fields
0 siblings, 1 reply; 9+ messages in thread
From: Chuck Lever @ 2009-01-12 23:04 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Linux NFS Mailing list
On Jan 12, 2009, at 5:29 PM, J. Bruce Fields wrote:
> On Mon, Jan 12, 2009 at 05:14:15PM -0500, Chuck Lever wrote:
>> User land must be running a portmapper that supports rpcbind protocol
>> version 4. Currently Linux's portmapper does not, which is why the
>> setting defaults to N. Recent Fedora distributions have replaced the
>> portmap daemon with a port of Sun's rpcbind daemon, which does
>> support
>> rpcbind version 4. But most other distributions still use portmap.
>>
>> I was hoping not to clutter svc_register() with logic to determine
>> which
>> is running, since it will add complexity with little value. And
>> eventually (or, soon, hopefully) everyone will run the rpcbind
>> port, and
>> that logic won't be needed at all.
>
> Other kernel developers and kernel testers are particularly valuable
> kernel users (by which I mean, valuable to us, since they do useful
> work
> for us) who often use new kernels on old distributions.
>> In addition, rpcbind/libtirpc are still not entirely stable (API/ABI-
>> wise) so it may be better to leave this as a hard compile-time switch
>> until distributions are comfortable replacing portmap with rpcbind.
>
> Making it easy to switch between portmap and (newer) rpcbind daemons
> might make it easier to test and debug the newer code.
>
> None of this is in contradiction to what you've said--it's a
> tradeoff--but on balance I'd prefer the additional svc_register()
> logic.
We really do want a hard switch to be able to turn this new feature off.
It's impossible for the kernel to detect which version of rpcbind is
running. Yes, it can tell if rpcbind v4 is supported or not, but what
if some versions of rpcbind have a bug or exhibit some incompatible or
undesirable behavior? We have already required an incompatible rev of
rpcbind once in the last six months because of bugs.
Because we have to support distributions like Ubuntu and Debian, which
package basically what is in upstream without a lot of testing, we
have to allow them to flip a switch to get the desired legacy
behavior, while still permitting users who want to experiment to do so
without a lot of trouble. It's also in the best interest of our
kernel community which you mention above.
Transitioning user space will be an effort for all distributions.
This CONFIG switch was added so they could do that without worrying
about their existing NFS implementation suddenly breaking after a
kernel upgrade. When/if it does misbehave, it is simply a matter of
disabling one config option to restore order.
It would probably be easy to add some logic that detects a protocol
version mismatch, and then prints a clearer error message. That's
what I had in mind to address bz 12256. But this is never going to be
perfect while user space IPv6 support is under development and in
transition.
> --b.
>
>>
>>> --b.
>>>
>>>> CONFIG_RPCSEC_GSS_KRB5=m
>>>> # CONFIG_RPCSEC_GSS_SPKM3 is not set
>>>>
>>>> ===== * ===== * ===== * =====
>>>>
>>>> # rpcinfo -p localhost
>>>> program vers proto port
>>>> 100000 2 tcp 111 portmapper
>>>> 100000 2 udp 111 portmapper
>>>> 100024 1 udp 34971 status
>>>> 100024 1 tcp 43460 status
>>>> 100005 1 udp 34365 mountd
>>>> 100005 1 tcp 44349 mountd
>>>> 100005 2 udp 34365 mountd
>>>> 100005 2 tcp 44349 mountd
>>>> 100005 3 udp 34365 mountd
>>>> 100005 3 tcp 44349 mountd
>>>>
>>>> ===== * ===== * ===== * =====
>>>>
>>>> lsmod
>>>>
>>>> Module Size Used by
>>>> nfs 206772 0
>>>> nfsd 185008 9
>>>> lockd 55160 2 nfs,nfsd
>>>> nfs_acl 2688 2 nfs,nfsd
>>>> auth_rpcgss 28548 1 nfsd
>>>> sunrpc 144584 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss
>>>> exportfs 3456 1 nfsd
>>>> fuse 42268 0
>>>> usbhid 13588 0
>>>> usbmouse 3712 0
>>>> usbkbd 4992 0
>>>> floppy 45348 0
>>>> pcspkr 2176 0
>>>> i2c_i801 7952 0
>>>> r8169 26500 0
>>>> i2c_core 17680 1 i2c_i801
>>>> mii 4224 1 r8169
>>>> snd_intel8x0 25500 0
>>>> snd_ac97_codec 88352 1 snd_intel8x0
>>>> ehci_hcd 28684 0
>>>> uhci_hcd 18444 0
>>>> ac97_bus 1536 1 snd_ac97_codec
>>>> snd_pcm 48008 2 snd_intel8x0,snd_ac97_codec
>>>> snd_timer 15364 1 snd_pcm
>>>> snd 34788 4
>>>> snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
>>>> usbcore 104760 6
>>>> usbhid,usbmouse,usbkbd,ehci_hcd,uhci_hcd
>>>> snd_page_alloc 7304 2 snd_intel8x0,snd_pcm
>>>> intel_agp 22588 1
>>>> agpgart 25520 1 intel_agp
>>>> button 5904 0
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-
>>>> nfs"
>>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [basic] nfsd failing to start
2009-01-12 23:04 ` Chuck Lever
@ 2009-01-13 3:34 ` J. Bruce Fields
0 siblings, 0 replies; 9+ messages in thread
From: J. Bruce Fields @ 2009-01-13 3:34 UTC (permalink / raw)
To: Chuck Lever; +Cc: Linux NFS Mailing list
On Mon, Jan 12, 2009 at 06:04:59PM -0500, Chuck Lever wrote:
> On Jan 12, 2009, at 5:29 PM, J. Bruce Fields wrote:
>> None of this is in contradiction to what you've said--it's a
>> tradeoff--but on balance I'd prefer the additional svc_register()
>> logic.
>
> We really do want a hard switch to be able to turn this new feature off.
>
> It's impossible for the kernel to detect which version of rpcbind is
> running. Yes, it can tell if rpcbind v4 is supported or not, but what
> if some versions of rpcbind have a bug or exhibit some incompatible or
> undesirable behavior? We have already required an incompatible rev of
> rpcbind once in the last six months because of bugs.
I'd consider that acceptable; we just use the highest protocol version,
and deal with the problem of buggy userspace separately.
> Because we have to support distributions like Ubuntu and Debian, which
> package basically what is in upstream without a lot of testing, we have
> to allow them to flip a switch to get the desired legacy behavior, while
> still permitting users who want to experiment to do so without a lot of
> trouble. It's also in the best interest of our kernel community which
> you mention above.
Another way users and distributors could flip that switch would be by
varying the choice of userland daemon to install and run. Then flipping
the switch would not require a kernel change.
> Transitioning user space will be an effort for all distributions. This
> CONFIG switch was added so they could do that without worrying about
> their existing NFS implementation suddenly breaking after a kernel
> upgrade. When/if it does misbehave, it is simply a matter of disabling
> one config option to restore order.
"apt-get remove rpcbind", for example, will often be more convenient
than replacing the kernel.
> It would probably be easy to add some logic that detects a protocol
> version mismatch, and then prints a clearer error message. That's what I
> had in mind to address bz 12256. But this is never going to be perfect
> while user space IPv6 support is under development and in transition.
Thanks, I agree that that would be an improvement.
I can't demand the runtime protocol-version switching at this point. I
still would consider it a further improvement, though, if someone had
the time to work on it.
--b.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-01-13 3:34 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-11 21:41 [basic] nfsd failing to start Harry P
[not found] ` <87zlhxy102.fsf-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
2009-01-12 17:24 ` J. Bruce Fields
2009-01-12 21:09 ` Harry P
2009-01-12 21:29 ` Chuck Lever
2009-01-12 22:00 ` J. Bruce Fields
2009-01-12 22:14 ` Chuck Lever
2009-01-12 22:29 ` J. Bruce Fields
2009-01-12 23:04 ` Chuck Lever
2009-01-13 3:34 ` J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox