Bug 21181 - nfs services doesn't start properly at boot
Summary: nfs services doesn't start properly at boot
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-03 21:35 CEST by Giuseppe Ghibò
Modified: 2017-07-09 03:08 CEST (History)
2 users (show)

See Also:
Source RPM: nfs-utils-1.3.4-2.mga6.src.rpm
CVE:
Status comment:


Attachments
rpcbind.spec patch (1.39 KB, patch)
2017-07-03 21:38 CEST, Giuseppe Ghibò
Details | Diff
patch for rpcbind.service (471 bytes, patch)
2017-07-03 21:38 CEST, Giuseppe Ghibò
Details | Diff

Description Giuseppe Ghibò 2017-07-03 21:35:52 CEST
After upgrading from mga5 to cauldron (mga6) the nfs services no longer starts automatically.

The nfs-server.service service is enabled.  Actually the problem seems in systemd scripts from nfs-utils as well as rpcbind (the rpc.nfsd is not executed at all). In fact the [nfsd] starts correctly if you start nfs-server manually later.
Comment 1 Giuseppe Ghibò 2017-07-03 21:38:10 CEST
Created attachment 9457 [details]
rpcbind.spec patch

Note that other distro seems having had a similar problem for rpcinfo. Many of them (e.g. Debian, Fedora, Omv) resolved introducing a dep to systemd-tmpfiles-setup.service, as shown in these patches. I tried also but seems not yet enough.
Comment 2 Giuseppe Ghibò 2017-07-03 21:38:48 CEST
Created attachment 9458 [details]
patch for rpcbind.service
Comment 3 Marja Van Waes 2017-07-05 10:41:36 CEST
Assigning to the registered maintainer.

Assignee: bugsquad => guillomovitch
CC: (none) => marja11

Comment 4 Giuseppe Ghibò 2017-07-05 13:24:07 CEST
I've a fixed for this in the new version rpcbind-0.25rc2 and nfs-utils 2.1.2-rc4. Still trying for the old (current) version. Still find a convenient way to upload them without messing up with versioning (i.e. bump release in the svn then have the old version too).
Comment 5 Giuseppe Ghibò 2017-07-06 13:54:35 CEST
I've uploaded a fixed version for the old (current) version in updates_testing for both rpcbind and nfs-utils.
Comment 6 Davy Defaud 2017-07-06 14:53:15 CEST
Already reported as bug #20255.

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

Resolution: (none) => DUPLICATE
CC: (none) => davy.defaud
Status: NEW => RESOLVED

Comment 7 Guillaume Rousse 2017-07-06 19:20:40 CEST
I'm a bit confused by multiple inputs here.

According to latest Day comment on #20255, the whole issue was fixed just by forcing nfs-server to wait for rpcbind. According to this new ticket, it seems to be actually insufficient, as rpcbind service needs also additional ordering constraints, and eventually get updated also... Closing this ticket as a duplicate  implies the opposite.

So basically I have 3 solutions:
- consider everything works OK, and do nothing
- add the ordering constraint in rpcbind
- add the ordering constraint and upgrade rpcbind
Comment 8 Giuseppe Ghibò 2017-07-06 19:50:37 CEST
Exactly, it was insufficient as #20255 was closed on february, while the problem was still there recently.

Solution is to upgrade rpcbind (I added also a cosmetic to nfs-utils that I found while working with release 2.1.2rc4).

As I said previosly I packaged also two new working versions based on rcpbind-0.25rc2 and nfs-utils-2.1.2rc4 which also works too. IMO those are good once the  final distro is out as updates for mga6, as well once once they bump to final version (0.25and 2.1.2) as they introduce new stuff for nfs4 to match features in newer kernels.
Comment 9 David Walser 2017-07-08 19:51:24 CEST
Thanks for the fixes Giuseppe.

Resolution: DUPLICATE => FIXED

Comment 10 David Walser 2017-07-09 03:08:53 CEST
When we update rpcbind and nfs-utils to their next releases, we also should update libtirpc to 1.0.2 final.

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