Bug 1293933
| Summary: | nfs-server fails to start on atomic host | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Dodson <sdodson> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED DUPLICATE | QA Contact: | Filesystem QE <fs-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | walters |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-28 14:42:28 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: | |||
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 It'd be best if nfs-utils learned to create those files automatically if they don't exist for compatibility with the OSTree model. 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. (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. 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. (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. *** Bug 1394395 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 1406164 *** |
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: