Bug 1477772

Summary:	upgrade from rpcbind-0.2.0-38.el7_3.1.x86_64 to rpcbind-0.2.0-42.el7.x86_64 reintroduces crash of rpcbind
Product:	Red Hat Enterprise Linux 7	Reporter:	Andy Feldt <afeldt>
Component:	rpcbind	Assignee:	Steve Dickson <steved>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Yongcheng Yang <yoyang>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	eguan, fsorenso, xzhou, yoyang
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-14 12:39:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Feldt 2017-08-02 21:48:05 UTC

Description of problem:
When updating from RHEL 7.3 to 7.4, rpcbind is also updated and the new version appears to reintroduce a crash of rpcbind fairly soon after startup in our NFS/NIS environment.

Version-Release number of selected component (if applicable):
0.2.0-42.el7.x86_64

How reproducible:
Every time after upgrade to RHEL 7.4, rpcbind crashes and NIS and NFS fail.

Steps to Reproduce:
1. Boot system
2. Wait less than 10 minutes typically
3. rpcbind will fail

Actual results:
rpcbind fails

Expected results:
rpcbind continues

Additional info:
Downgrading to 0.2.0-38.el7_3.1.x86_64 corrects the problem.  This must be done on both the NFS/NIS servers and clients.

Comment 2 Andy Feldt 2017-09-13 15:59:36 UTC

A recent test shows that this is no longer an issue.  I have updated multiple components since then (including the kernel) and so I do not know which caused the problem to no longer exist.  In any case I will close this bug.

Comment 3 Steve Dickson 2017-09-14 12:39:55 UTC

(In reply to Andy Feldt from comment #2)
> A recent test shows that this is no longer an issue.  I have updated
> multiple components since then (including the kernel) and so I do not know
> which caused the problem to no longer exist.  In any case I will close this
> bug.

Thank you for your testing!