Bug 1451567 - No listen on udp after updating to 2.1.1-2.rc1.f25
Summary: No listen on udp after updating to 2.1.1-2.rc1.f25
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-17 05:08 UTC by Akira TAGOH
Modified: 2017-06-07 20:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-06 14:34:36 UTC


Attachments (Terms of Use)

Description Akira TAGOH 2017-05-17 05:08:39 UTC
Description of problem:
rpc.nfsd no longer listens on udp after updating to 2.1.1-2.rc1.f25 or later. this isn't a trivial change which shouldn't be happened with the update.

Version-Release number of selected component (if applicable):
nfs-utils-2.1.1-5.rc2.fc25.x86_64

How reproducible:
always

Steps to Reproduce:
1.systemctl start nfs
2.rpcinfo -p | grep nfs
3.

Actual results:
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl

Expected results:
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl

Additional info:

Comment 1 Steve Dickson 2017-06-01 17:32:46 UTC

*** This bug has been marked as a duplicate of bug 1450765 ***

Comment 2 Akira TAGOH 2017-06-02 09:57:22 UTC
Hey, why is this a dup of bug#1450765?
I have rpcbind-0.2.4-6.rc2.fc25.x86_64 installed but there are still no listens on udp.

This can be worked around by adding --udp to $RPCNFSDARGS in /etc/sysconfig/nfs or "udp=y" at [nfsd] section in /etc/nfs.conf but there wasn't any announcement for such drastic changes in updates.

I don't say anything on it for the future releases but should be reverted for updates.

Comment 3 Steve Dickson 2017-06-05 17:24:17 UTC
(In reply to Akira TAGOH from comment #2)
> Hey, why is this a dup of bug#1450765?
> I have rpcbind-0.2.4-6.rc2.fc25.x86_64 installed but there are still no
> listens on udp.
you are right....this is no a dup... 

> 
> This can be worked around by adding --udp to $RPCNFSDARGS in
> /etc/sysconfig/nfs or "udp=y" at [nfsd] section in /etc/nfs.conf but there
> wasn't any announcement for such drastic changes in updates.
With the upstream commit:

commit fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
Author: Jeff Layton <jlayton@redhat.com>
Date:   Wed Apr 5 13:26:49 2017 -0400

    nfsd: don't enable a UDP socket by default

udp sockets are off by default.

> 
> I don't say anything on it for the future releases but should be reverted
> for updates.
I forgot all about that commit... I probably should have left
it on for released versions... 

Thinking about it... why do you needed udp? using tcp is the way to go...

Comment 4 Akira TAGOH 2017-06-06 07:59:22 UTC
Dev VM instance of some project I'm getting involved forcibly uses nfs mount over udp. I don't know why they prefer it.

Comment 5 Steve Dickson 2017-06-06 14:33:34 UTC
(In reply to Akira TAGOH from comment #4)
> Dev VM instance of some project I'm getting involved forcibly uses nfs mount
> over udp. I don't know why they prefer it.

I would take a hard look at because you really don't want
to be using udp if you doing a lot of I/O. TCP is
a much better protocol because it knows how to manage
network congestion.

Comment 6 Steve Dickson 2017-06-06 14:34:36 UTC
I'm going to close this off since there is a valid workaround...

Comment 7 Akira TAGOH 2017-06-07 09:41:18 UTC
Well, "what's better" is another story. what I'm saying here is the drastic changes like changing the default behavior shouldn't be happened in the updates and this had been made without any notice and logs even. that's really the worst case.

Comment 8 Steve Dickson 2017-06-07 20:28:27 UTC
(In reply to Akira TAGOH from comment #7)
> Well, "what's better" is another story. what I'm saying here is the drastic
> changes like changing the default behavior shouldn't be happened in the
> updates and this had been made without any notice and logs even. that's
> really the worst case.

I completely agree... it was a mistake on my part... my apologies


Note You need to log in before you can comment on or make changes to this bug.