Bug 10646
Summary: | NFS init script is broken | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | martin |
Component: | nfs-utils | Assignee: | Pete Zaitcev <zaitcev> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | dr, marc.schmitt, mcwst18 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-02-08 17:15:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
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 *** Bug 11491 has been marked as a duplicate of this bug. *** 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. 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. >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.
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. 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. 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? 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. leon 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. 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 Afterwards: 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. assigned to johnsonm |
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: 28c28 < [ -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).