Bug 1293933 - nfs-server fails to start on atomic host
nfs-server fails to start on atomic host
Status: CLOSED DUPLICATE of bug 1406164
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nfs-utils (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Steve Dickson
Filesystem QE
:
: 1394395 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-23 10:11 EST by Scott Dodson
Modified: 2017-02-28 09:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-02-28 09:42:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Dodson 2015-12-23 10:11:25 EST
Description of problem:
It's probably unwise to run atomic host as an NFS server and maybe there are plans to containerize it? However nfs-utils package is installed but nfs-server fails due to missing /var/lib/nfs/{etab,mtab,state} files.

Version-Release number of selected component (if applicable):
2015-12-03 19:40:36     7.2.1     aaf67b91fa     rhel-atomic-host     rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard

How reproducible:
100%

Steps to Reproduce:
1. systemctl start nfs-server

Actual results:
rpc.mountd fails to start

systemd[1]: Starting NFSv4 ID-name mapping service...
systemd[1]: Reached target Host and Network Name Lookups.
systemd[1]: Starting Host and Network Name Lookups.
systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
systemd[1]: Reached target RPC Port Mapper.
systemd[1]: Starting RPC Port Mapper.
systemd[1]: Started Kernel Module supporting RPCSEC_GSS.
systemd[1]: Starting NFS Mount Daemon...
systemd[1]: Started RPC security service for NFS client and server.
systemd[1]: Started RPC security service for NFS server.
systemd[1]: Starting RPC bind service...
rpc.statd[2796]: Version 1.3.0 starting
rpc.statd[2796]: Flags: TI-RPC
rpc.statd[2796]: Initializing NSM state
systemd[1]: Started RPC bind service.
systemd[1]: Started NFSv4 ID-name mapping service.
rpc.mountd[2794]: couldn't open /var/lib/nfs/etab
systemd[1]: nfs-mountd.service: control process exited, code=exited status=1
systemd[1]: Failed to start NFS Mount Daemon.
systemd[1]: Dependency failed for NFS server and services.
systemd[1]: Job nfs-server.service/start failed with result 'dependency'.
systemd[1]: Unit nfs-mountd.service entered failed state.
systemd[1]: nfs-mountd.service failed.


Expected results:
nfs-server starts successfully

Additional info:
Comment 2 Scott Dodson 2015-12-23 10:50:10 EST
I was pointed to this mailing list discussion on the topic. It seems like the outcome was that installation of nfs-utils installed only for client use cases though there were some differing opinions.

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-October/msg00081.html
Comment 3 Colin Walters 2016-01-04 11:45:56 EST
It'd be best if nfs-utils learned to create those files automatically if they don't exist for compatibility with the OSTree model.
Comment 4 Scott Dodson 2016-01-04 11:49:35 EST
Oh, sorry, one important note I should've added is that those files do exist in the RPMs. So I suspect this is a problem with atomic build process.
Comment 5 Colin Walters 2016-01-04 11:55:56 EST
(In reply to Scott Dodson from comment #4)
> Oh, sorry, one important note I should've added is that those files do exist
> in the RPMs. So I suspect this is a problem with atomic build process.

It's a currently intentional part of rpm-ostree - we only take directories from RPMs, but the goal is to convert all content in /var into systemd-tmpfiles units owned by the packages.

This *could* change but it's just better if /var stays clean by default so that backups only snapshot data you care about, etc.

e.g. if a system isn't actually using NFS, no reason to back up those files, etc.
Comment 6 Steve Dickson 2016-01-04 15:24:25 EST
First of all.. this will have to go through upstream so
there should probably be a Fedora bz opened up
so people see it..

(In reply to Colin Walters from comment #5)
> (In reply to Scott Dodson from comment #4)
> > Oh, sorry, one important note I should've added is that those files do exist
> > in the RPMs. So I suspect this is a problem with atomic build process.
> 
> It's a currently intentional part of rpm-ostree - we only take directories
> from RPMs, but the goal is to convert all content in /var into
> systemd-tmpfiles units owned by the packages.
While its true /var/lib/nfs/{etab,mtab,rmtab} are installed
from the RPM... Its not clear to me they need to
be since they are used but they are legacy ones
used with v3, so maybe something could be done.

Also these are all defined at compile time so
they could be moved other places.

> systemd[1]: Started NFSv4 ID-name mapping service.
> rpc.mountd[2794]: couldn't open /var/lib/nfs/etab
exportfs could create this since it has to be run
before mountd but we would have to deal with race
conditions.

> 
> This *could* change but it's just better if /var stays clean by default so
> that backups only snapshot data you care about, etc.
The directories under /var/lib/nfs store state that is
needed for reboots so throwing them under systemd-tmpfiles
I don't think will work.
Comment 7 Colin Walters 2016-01-04 15:37:08 EST
(In reply to Steve Dickson from comment #6)
> 
> Also these are all defined at compile time so
> they could be moved other places.

I think the location is fine.

> The directories under /var/lib/nfs store state that is
> needed for reboots so throwing them under systemd-tmpfiles
> I don't think will work.

On an OSTree system, /var is persistent by default.  systemd-tmpfiles is just a good way to ensure directories (and files) exist there on boot if they didn't already.
Comment 8 Colin Walters 2016-11-11 16:52:03 EST
*** Bug 1394395 has been marked as a duplicate of this bug. ***
Comment 9 Colin Walters 2017-02-28 09:42:28 EST

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

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