RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1203820 - First nfs mount command taking long time after every reboot.
Summary: First nfs mount command taking long time after every reboot.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpcbind
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Yongcheng Yang
URL:
Whiteboard:
: 1206262 (view as bug list)
Depends On: 1199644
Blocks: 1133060
TreeView+ depends on / blocked
 
Reported: 2015-03-19 18:06 UTC by VIKRANT
Modified: 2019-10-10 09:42 UTC (History)
17 users (show)

Fixed In Version: rpcbind-0.2.0-27.el7
Doc Type: Bug Fix
Doc Text:
Cause: The first NFS mount after the system rebooted Consequence: The mount would hang for noticeable long time before successfully completing Fix: Added support for systemd socket activation to rpcbind (see bz1203820) Result: The first NFS mount, after a reboot, no longer hang.
Clone Of:
Environment:
Last Closed: 2015-11-19 05:32:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1158164 0 unspecified CLOSED Start of rpc-statd.service is very slow 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1243763 0 unspecified CLOSED Pacemaker Systemd init doesn't wait the system to be online before starting, letting NFS resources to fail 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 1397363 0 None None None Never
Red Hat Product Errata RHBA-2015:2205 0 normal SHIPPED_LIVE rpcbind bug fix update 2015-11-19 08:17:40 UTC

Internal Links: 1243763

Description VIKRANT 2015-03-19 18:06:47 UTC 
Description of problem: nfs mount command after the reboot is taking 1 minute to mount the share subsequent mounts are getting mounted in expected time.


Version-Release number of selected component (if applicable):  
3.10.0-229.el7.x86_64
Red Hat Enterprise Linux Server release 7.1 (Maipo)

How reproducible: Everytime.


Steps to Reproduce:
1. mount the nfs share using below command.

[root@Node71 ~]# time mount.nfs -o vers=3 -vvv 192.168.111.121:/boot /mnt
mount.nfs: timeout set for Thu Mar 19 07:01:11 2015
mount.nfs: trying text-based options 'vers=3,addr=192.168.111.121'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.111.121 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.111.121 prog 100005 vers 3 prot UDP port 34469

real    1m0.460s                <<<<<
user    0m0.012s
sys     0m0.027s

2. unmount the share and mount it again it will not take much time now.

[root@Node71 ~]# time mount.nfs -o vers=3 -vvv 192.168.111.121:/boot /mnt
mount.nfs: timeout set for Thu Mar 19 07:04:07 2015
mount.nfs: trying text-based options 'vers=3,addr=192.168.111.121'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.111.121 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.111.121 prog 100005 vers 3 prot UDP port 34469

real    0m0.033s             <<<<<
user    0m0.000s
sys     0m0.018s

3. Reboot the server again we are back at step 1.

Actual results: Time delay while mounting the nfs share seems to be due to  starting of the nfs client services. Saw 1 minute delay in start of rpc-statd.service

[root@Node71 ~]# journalctl -u rpc-statd.service
-- Logs begin at Thu 2015-03-19 06:57:06 EDT, end at Thu 2015-03-19 07:30:24 EDT. --
Mar 19 06:59:11 Node71 systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Mar 19 06:59:11 Node71 rpc.statd[2518]: Version 1.3.0 starting
Mar 19 06:59:11 Node71 rpc.statd[2518]: Flags: TI-RPC                               <<<<<<<
Mar 19 07:00:11 Node71 systemd[1]: Started NFS status monitor for NFSv2/3 locking.. <<<<<<<

[root@Node71 ~]# journalctl -u rpcbind
-- Logs begin at Thu 2015-03-19 06:57:06 EDT, end at Thu 2015-03-19 07:30:24 EDT. --
Mar 19 06:59:11 Node71 systemd[1]: Starting RPC bind service...
Mar 19 06:59:11 Node71 systemd[1]: Started RPC bind service.


Expected results: NFS mount command at first attempt should not take 1 minute and rpc.statd nfs-lock should start at boot.

Additional info: Below are the /var/log/message logs.

Mar 19 06:59:11 Node71 systemd: Starting Preprocess NFS configuration...
Mar 19 06:59:11 Node71 systemd: Starting RPC Port Mapper.
Mar 19 06:59:11 Node71 systemd: Reached target RPC Port Mapper.
Mar 19 06:59:11 Node71 systemd: Starting Host and Network Name Lookups.
Mar 19 06:59:11 Node71 systemd: Reached target Host and Network Name Lookups.
Mar 19 06:59:11 Node71 systemd: Started Preprocess NFS configuration.
Mar 19 06:59:11 Node71 systemd: Starting NFS status monitor for NFSv2/3 locking....
Mar 19 06:59:11 Node71 rpc.statd[2518]: Version 1.3.0 starting
Mar 19 06:59:11 Node71 rpc.statd[2518]: Flags: TI-RPC
Mar 19 06:59:11 Node71 systemd: Starting RPC bind service...
Mar 19 06:59:11 Node71 systemd: Started RPC bind service.                           <<<<<<
Mar 19 07:00:11 Node71 systemd: Started NFS status monitor for NFSv2/3 locking..    <<<<<<
Mar 19 07:00:11 Node71 kernel: FS-Cache: Loaded
Mar 19 07:00:11 Node71 kernel: RPC: Registered named UNIX socket transport module.
Mar 19 07:00:11 Node71 kernel: RPC: Registered udp transport module.
Mar 19 07:00:11 Node71 kernel: RPC: Registered tcp transport module.
Mar 19 07:00:11 Node71 kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 19 07:00:11 Node71 kernel: FS-Cache: Netfs 'nfs' registered for caching
Comment 3 Scott Mayhew 2015-03-31 14:18:57 UTC 
Added bug 1199644 to the Depends On field since the patch from Fedora bug 1158164 requires libsystemd, which isn't in RHEL 7 yet.
Comment 7 Yongcheng Yang 2015-04-29 09:17:14 UTC 
*** Bug 1206262 has been marked as a duplicate of this bug. ***
Comment 16 errata-xmlrpc 2015-11-19 05:32:17 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2205.html
Note You need to log in before you can comment on or make changes to this bug.