Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionOrion Poplawski
2012-09-19 17:16:09 UTC
Description of problem:
Apparently if rpc.statd starts to early it can get into a bad state:
Sep 11 16:01:28 hawk rpc.statd[1303]: Version 1.2.3 starting
Sep 11 16:01:28 hawk sm-notify[1304]: Version 1.2.3 starting
Sep 11 16:01:28 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:28 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:29 hawk kernel: RPC: Registered named UNIX socket transport module.
Sep 11 16:01:29 hawk kernel: RPC: Registered udp transport module.
Sep 11 16:01:29 hawk kernel: RPC: Registered tcp transport module.
Sep 11 16:01:29 hawk kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Sep 11 16:01:41 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:41 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:45 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:45 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:57 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:57 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:58 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
Sep 11 16:01:58 hawk rpc.statd[1303]: nsm_parse_reply: can't decode RPC reply
....
Restarting rpc.statd fixes things. From the log it does look like rpc.statd starts before rpc is fully set up going by the kernel modules. Not sure the proper way to make it wait. Perhaps the rpcbind init script needs to not return until it is fully initialized?
This machine is an old dual processor PIII, so perhaps the combination allows the race to occur.
Version-Release number of selected component (if applicable):
nfs-utils-1.2.3-26.el6.i686
rpcbind-0.2.0-9.el6.i686
How reproducible:
Not very it seems, only seen once, but unless you're checking logs you won't see it.