Bug 1414601

Summary: rpcbind 0.2.3-14.rc2.fc24 fails to start at boot when /var is an LVM volume
Product: [Fedora] Fedora Reporter: John Hebron <hebron>
Component: rpcbindAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: steved
Target Milestone: ---   
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-01-19 15:30:40 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 John Hebron 2017-01-19 00:34:24 UTC
Description of problem:

rpcbind 0.2.3-14.rc2.fc24 fails to start at boot when /var is an LVM volume.
However, rpcbind 0.2.3-10.rc1.fc24 works fine.
This only happens when /var is an LVM volume.

Version-Release number of selected component (if applicable):

0.2.3-14.rc2.fc24

How reproducible:

100%

Steps to Reproduce:
1.  Make a Fedora 24 host in which /var is an LVM volume and rpcbind is 0.2.3-10.rc1.fc24.
2.  dnf update rpcbind
3.  reboot

Actual results:
rpcbind and its dependencies such as ypbind and autofs fail to start at boot.

Expected results:
rpcbind and its dependencies start fine at boot.

Additional info:
This only happens when /var is an LVM volume.

Comment 1 Steve Dickson 2017-01-19 15:30:40 UTC
With the latest rpcbind version (rpcbind-0.2.3-15.rc2.fc24) 
/var is no longer used in the path to the state directory.
So this problem should not occur...

I'm going to close this but feel free to reopen 
if this is not the case.

Comment 2 John Hebron 2017-01-20 00:59:09 UTC
(In reply to Steve Dickson from comment #1)
> With the latest rpcbind version (rpcbind-0.2.3-15.rc2.fc24) 
> /var is no longer used in the path to the state directory.
> So this problem should not occur...
> 
> I'm going to close this but feel free to reopen 
> if this is not the case.

I don't see this version on any of the mirrors I looked at.
All I see in pub/fedora/linux/updates/24/x86_64/r/ is
rpcbind-0.2.3-14.rc2.fc24

Comment 3 Steve Dickson 2017-01-20 13:00:16 UTC
(In reply to John Hebron from comment #2)
> (In reply to Steve Dickson from comment #1)
> > With the latest rpcbind version (rpcbind-0.2.3-15.rc2.fc24) 
> > /var is no longer used in the path to the state directory.
> > So this problem should not occur...
> > 
> > I'm going to close this but feel free to reopen 
> > if this is not the case.
> 
> I don't see this version on any of the mirrors I looked at.
> All I see in pub/fedora/linux/updates/24/x86_64/r/ is
> rpcbind-0.2.3-14.rc2.fc24

The package is still in testing phase 
   https://bodhi.fedoraproject.org/updates/FEDORA-2017-ae8bb3b08f

It still need one more +1 karma to make it into stable

Here is the build
  https://bodhi.fedoraproject.org/updates/FEDORA-2017-ae8bb3b08f

If you want to give it a test run...

Comment 4 John Hebron 2017-01-26 01:35:33 UTC
(In reply to Steve Dickson from comment #3)
> (In reply to John Hebron from comment #2)
> > (In reply to Steve Dickson from comment #1)
> > > With the latest rpcbind version (rpcbind-0.2.3-15.rc2.fc24) 
> > > /var is no longer used in the path to the state directory.
> > > So this problem should not occur...
> > > 
> > > I'm going to close this but feel free to reopen 
> > > if this is not the case.
> > 
> > I don't see this version on any of the mirrors I looked at.
> > All I see in pub/fedora/linux/updates/24/x86_64/r/ is
> > rpcbind-0.2.3-14.rc2.fc24
> 
> The package is still in testing phase 
>    https://bodhi.fedoraproject.org/updates/FEDORA-2017-ae8bb3b08f
> 
> It still need one more +1 karma to make it into stable
> 
> Here is the build
>   https://bodhi.fedoraproject.org/updates/FEDORA-2017-ae8bb3b08f
> 
> If you want to give it a test run...

Thanks, I installed rpcbind-0.2.3-15.rc2.fc24, and rpcbind still
fails to start at boot, but for a different reason:

  rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory

I think rpcbind is trying to start too soon in the boot process.