Bug 10646 - NFS init script is broken
Summary: NFS init script is broken
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
: 11491 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-04-07 19:32 UTC by martin
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-08 17:15:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description martin 2000-04-07 19:32:06 UTC
The /etc/rc.d/init.d/nfs rc script is broken.  It is responsible for
starting mountd, which monitors NFS mount requests on the local machine,
but prior to starting mountd, it checks to see if /etc/exports exists and
contains characters, and if it does not it exits with a success status.

This behavior is totally brain-dead.  /etc/exports has no bearing on
whether a client machine will want to mount nfs filesystems.  In addition,
if an administrator uses this script to start nfs, presumably there is a
reason for doing so (likely that NFS services are desired)! If the daemons
don't start for WHATEVER reason, it is only logical that you return
failure, to call attention to the fact that the daemons did not start.

The simple fix is this:

< [ -s /etc/exports ] || exit 0
> #[ -s /etc/exports ] || exit 0

However, this is still a brain-damaged hack, since the nfsd daemon will
now start whether or not there is anything to export. This may not be what
the user/adminstrator wants.  The correct behavior is either to start
mountd in netfs where it belongs, or in another file seperate from nfsd,
or possibly to make which daemons start configurable by variables in a
file in the /etc/sysconfig directory.  I vote for netfs, since this
function seems to belong to that script.

It also does not address the success/failure issue when the daemons fail
to start (i.e. because they don't exist on the system).

Comment 1 Pekka Savola 2000-04-10 06:17:59 UTC
mountd is (at least _was_) not required to mount NFS filesystems.  I would
rather not put it in netfs, because personally I don't like to have any extra
network services running on any workstation.

Just my .02c, HTH

Comment 2 mcwst18 2000-05-17 19:57:59 UTC
*** Bug 11491 has been marked as a duplicate of this bug. ***

Comment 3 martin 2000-05-17 20:26:59 UTC
It does seem, on further investigation, that mountd is not (supposed to be)
required to mount NFS filesystems... nevertheless the behavior I described is
accurate.  On the affected systems, commenting out that line in
/etc/rc.d/init.d/nfs does fix the problem.  Upon further reflecton, I don't know
WHY it fixes it, and I don't have time to look at it in more detail right now.

Comment 4 mcwst18 2000-05-17 20:36:59 UTC
Upon doing some research myself, it appears that the problem is the lack of
clarity in init-script naming.

init.d/nfs is the NFS-server script (perhaps more appropriate called the nfsd or
nfs-server script), and init.d/netfs is the NFS-client script.  The behavior of
init.d/nfs is essentially correct, but the name is misleading.

Comment 5 martin 2000-05-17 21:26:59 UTC
>init.d/nfs is the NFS-server script (perhaps more appropriate
> called the nfsd or nfs-server script), and init.d/netfs is the
> NFS-client script.  The behavior of init.d/nfs is essentially
> correct, but the name is misleading.

Regardless of what which script is called and what they're supposed to do, nfs
mounts (i.e. client side) refuse to mount unless line 28 of init.d/nfs is
commented out. This is true on every machine I've tested this on (3 total to
date).  The systems in question are all in use in production so I can't play
with them, but if I get the chance (which is highly unlikely any time soon,
given my current workload) I'll set up another box and see what the deal is.

Comment 6 mcwst18 2000-05-17 22:48:59 UTC
You're approaching it the wrong way: first of all, if you're not running an NFS
server on the system, there should not be a link to init.d/nfs in your default
runlevel rc directory.  That's part of system administration.

If you want to leave it in, try creating an /etc/exports with nothing but
whitespace and hashes -- a single space, or a single comment, will do.  But you
shouldn't leave it in if the system isn't an NFS server.

Comment 7 martin 2000-05-18 14:46:59 UTC
You are completely missing the point dude; the netfs script runs BEFORE the nfs
script.  Yet when we try to mount NFS filesystems, they WILL NOT MOUNT until the
nfs script is run, and ONLY if the line that checks for /etc/exports is
commented out.

Your comment about the link being inappropriate is correct, but it is apparently
installed there by default when you select "install everything" at install time,
and in any event NFS fs's wouldn't mount until it was run. I don't have a good
explanation, but that's the behavior I observed.

Comment 8 mcwst18 2000-05-18 15:53:59 UTC
I realize it's not my job to examine the bug, but now I'm interested.  Are you
saying that when netfs is run, nothing is successfully mounted, unless the nfs
script has already been run?  How sure are you that line 28 must be commented
out -- have you tried just running exportfs -r, or rpc.rquotad, rpc.mountd
$RPCMOUNTDOPTS, or rpc.nfsd $RPCNFSDCOUNT, or touch /var/lock/subsys/nfs?  Also,
does 'echo > /etc/exports' allow you to uncomment line 28 in init.d/nfs?

Comment 9 leon 2000-06-02 01:33:00 UTC
A local mountd is NOT required to use a remote nfs.

I don't even let nfs be run.
delete nfs out of your run levels if you dont use it.

If you think  the nfs  init script needs to be run, there must be something
tricking you. Perhaps you also rebooted the server in between changes,
or  caused some failure due to ip address changes. 

But something else tricked you because mountd is not needed for
the mounting of network filesystems;  mountd is  ONLY needed for exporting nfs .

This very machine has nfs mounts active, but the nfs script was never even run.


Comment 10 Marc Schmitt 2000-06-15 10:16:13 UTC
I found a problem with the /etc/rc.d/init.d/nfs script which will cause the OS
to hang. I have the following setup on machine yyy:

chkconfig --list nfs
nfs            	0:off	1:off	2:off	3:off	4:off	5:off	6:off
chkconfig --list nfslock
nfslock        	0:off	1:off	2:off	3:on	4:on	5:on	6:off

cat /etc/exports
/local/Office51 xxx(rw)

Now I execute: /etc/rc.d/init.d/nfs restart
(note: nfs was not started yet)

The script will quickly show failed and then ok.
Now I mount the exported directory from the machine xxx like this:
mount yyy:/local/Office51 /tmp/Office51

After a while, mount comes back with:
mount: RPC: Timed out

Meanwhile machine yyy died, although it responds still to ping. The shells
freeze, no remote login possible.

I repeated the procedure 5 times, it had always the same effect.

This may not be related to the problem you describe above, but it matches the
topic (NFS init script is broken). Using `/etc/rc.d/init.d/nfs start` instead of
`/etc/rc.d/init.d/nfs restart` works fine and does not crash the OS.

Comment 11 Marc Schmitt 2000-06-20 07:10:04 UTC
Encouraged by Vincent, I did some further investigation.
I`m using the default initscripts suit that comes with RH 6.2 (5.00-1).

NFS start does the following:
daemon rpc.rquotad 
daemon rpc.mountd $RPCMOUNTDOPTS 
daemon rpc.nfsd $RPCNFSDCOUNT 
touch /var/lock/subsys/nfs

NFS restart this:
killproc rpc.mountd 
daemon rpc.mountd $RPCMOUNTDOPTS 
/usr/sbin/exportfs -r 
touch /var/lock/subsys/nfs 

When trying to use `nfs restart` before `nfs start` ever was invoked, `nfs
restart` will fail to kill rpc.mountd, then start it.
So before `nfs restart` I have:
root       344   343  0 09:23 ?        00:00:00 [rpciod] 
root       353     1  0 09:23 ?        00:00:00 rpc.statd 

root       344   343  0 09:23 ?        00:00:00 [rpciod] 
root       353     1  0 09:23 ?        00:00:00 rpc.statd 
root      1393     1  0 09:40 ?        00:00:00 rpc.mountd --no-nfs-version 3

What we miss is rpc.rquoatd, which only is started from `nfs start`.

This may cause the machine to hang when another machine tries to export a
directory. /var/log/messages gives no further information, the server instantly
freezes after mounting, no messages are appended.

Comment 12 Cristian Gafton 2000-08-09 02:36:17 UTC
assigned to johnsonm

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