Bug 180425 - net-fs/nfs-utils - rpc.idmapd init script can't start because rpc_pipefs isn't created
|
Bug#:
180425
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: net-fs@gentoo.org
|
Reported By: mvolaski@aecom.yu.edu
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: net-fs/nfs-utils - rpc.idmapd init script can't start because rpc_pipefs isn't created
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-31 09:20 0000
|
In an existing, older installation where nfsv4 client was working, emerging to
the current version caused it stop working. Among other problems, the init
script rpc.idmapd complains
* Mounting RPC pipefs ...
mount: mount point /var/lib/nfs/rpc_pipefs does not exist
[ !! ]
I believe it should be created by the script or at the very least by on
installation of the nfsutils ebuild.
it works with nfs-utils-1.1.0 here,
I think it's either nfsmount or nfs init script that creates this folder.
This is a real bug, but usually not triggered.
The file is created by /etc/init.d/nfs, but nfs isn't a dependency of
rpc.idmapd. So you can actually try to start rpc.idmapd before the directory is
created, which generates the error.
The nfs init script does indeed have to code to create this directory, but it's
still not working on my system with nfs-utils-1.1.0-r1.
I guess the init.d scripts have to be refactored. AFAIK, pipefs is used by
different daemons (at least rpc.idmapd and rpc.gssd), so mounting (and checking
for directory existence) should be separated into another init.d script.
Currently, if rpc.gssd get started before rpc.idmapd, I get this error:
Oct 10 12:08:26 [rpc.gssd] ERROR: failed to open /var/lib/nfs/rpc_pipefs/nfs:
No such file or directory_
When we are at refactoring init.d scripts, I would propose splitting rpc.gssd
(used by client) and rpc.svcgssd (used by server). I see no point in starting
both daemons on client-only or server-only machines.
(In reply to comment #4)
> When we are at refactoring init.d scripts, I would propose splitting rpc.gssd
> (used by client) and rpc.svcgssd (used by server). I see no point in starting
> both daemons on client-only or server-only machines.
Probably it would be best to have only two scripts, one for "server" and
another for "client". Too many scripts are a mess for those (like me) that only
want to start the server when needed.
As for the server script, there should be a better way for detecting/specifying
if nfs4 is to be used (to start idmapd). This only works for a client, if there
is a nfs4 line in fstab. Afaik there's currently no auto-detection for a
server, nor a way to set it to be started with nfs.
I would vote for split init.d scripts, but with proper (autodetected?)
dependencies. So you just have to start nfs for server and nfsmount for client.
And also configure something in conf.d properly.
Single init.d script is not good. When single service crashs, you cannot
trivially start/stop it and you will have inconsistent system state.
Fair enough. I wonder when will the net fs guys say something.. They seem a bit
silent.
