LinuxQuestions.org - Why and how settings of mounting NFS in /etc/rc.local are overrided with /etc/fstab?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Why and how settings of mounting NFS in /etc/rc.local are overrided with /etc/fstab? (https://www.linuxquestions.org/questions/linux-newbie-8/why-and-how-settings-of-mounting-nfs-in-etc-rc-local-are-overrided-with-etc-fstab-4175503207/)

Why and how settings of mounting NFS in /etc/rc.local are overrided with /etc/fstab?

I have a RHEL5.5 host as NFS Client.
I didn't do the configuration and I don't know why it is that and ...

I found mount command in /etc/rc.local and also mount settings in /etc/fstab
I checked /proc/mounts and discovered that the mount options not follow those in /etc/rc.local
I googled some pages and it seems /etc/rc.local is the last script excuted when system startup

So now I'm not sure when and how were the mount options overrided and I have to find out.

Is /etc/fstab applied after or before /etc/rc.local?
Or there could be some script mounting NFS after /etc/rc.local

Please point me some direction to inspect the reason
THANX~!!

/etc/fstab is used during system setup - RHEL 5.5 still uses a standard init, so the mounts are done by the contents /etc/rc[2345].d (as appropriate for the run level). NFS mounts are normally done by the S25netfs scripts during boot. local should be processed by S99local.

Since the startup scripts are run in standard sort order (Snn), that makes the NFS mounts (S25*) done before local (S99).

BTW, if network manager is present and being used, all bets are off. It hasn't been called NetworkMangler for nothing. The problem is that the network isn't necessarily ready when NetworkManager finishes... thus NFS mounts have been known to fail the first time. By the time rc.local gets run, it might be ready...

The filesystem was probably already mounted by the "netfs" service, which occurs before rc.local is run, and thus the mount in rc.local simply fails. I see several alternatives:

Just put the options you want in /etc/fstab and let the netfs auto-mount do the work,
Remove that entry from /etc/fstab entirely,
Include "noauto" in the options in /etc/fstab so that the auto-mount will skip that entry,
In rc.local, include "remount" in the options so that the mount command will (attempt to) replace the current mount options with the ones you specify.

Option 4 is of course going to fail if, for some reason, the filesystem was not already mounted.

Why do you want to do this in rc.local instead of just setting up /etc/fstab with the correct options and letting netfs take care of the mount?

Do you know what is to be mounted?

If so let us know what is to be mounted.

Please let us know :

1.What is to be mounted?
2.Contents of rc.local
3.Contents of /etc/fstab

Can you manually mount the nfs share?

First thanks for your replys.
There is a trouble that the host in problem is actually one of my customer's production servers,
so I can't get access to it at once.
But I can give you the content of rc.local and /proc/mounts

rc.local

Code:

#!/bin/sh

#

# This script will be executed *after* all the other init scripts.

# You can put your own initialization stuff in here if you don't

# want to do the full Sys V style init stuff.



touch /var/lock/subsys/local

mount -t nfs -o rw,bg,soft 10.1.XXX.XXX:/volumes/nrenas_vol1/appnre /var/aptg

bash /home/nre/scripts/roaming/maintain/autostart.NRE_Handlers.sh

/proc/mounts

Code:

rootfs / rootfs rw 0 0

/dev/root / ext3 rw,data=ordered 0 0

/dev /dev tmpfs rw 0 0

/proc /proc proc rw 0 0

/sys /sys sysfs rw 0 0

/proc/bus/usb /proc/bus/usb usbfs rw 0 0

devpts /dev/pts devpts rw 0 0

/dev/sda1 /boot ext3 rw,data=ordered 0 0

tmpfs /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0

/etc/auto.misc /misc autofs rw,fd=7,pgrp=6118,timeout=300,minproto=5,maxproto=5,indirect 0 0

-hosts /net autofs rw,fd=13,pgrp=6118,timeout=300,minproto=5,maxproto=5,indirect 0 0

10.1.XXX.XXX:/volumes/nrenas_vol1/appnre /var/aptg nfs rw,vers=3,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=10.1.213.83 0 0

And about /etc/fstab, I'm very sorry that I found that there is no nfs mounting point in /etc/fstab.
So the actual problem is "NFS mounting options in rc.local are overrided somewhere at sometime"

I did some experiments on my own RHEL 5.5 machine, mount manually in shell and I found that:
If mounted with same options the system says that the mount point is already mount or busy,
BUT when I change some options I can mount with no error message,
and the new duplicated mount point shows up in /proc/mounts.
like this

Code:

10.1.XXX.XXX:/volumes/nrenas_vol1/appnre /var/aptg nfs rw,vers=3,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=10.1.213.83 0 0

10.1.XXX.XXX:/volumes/nrenas_vol1/appnre /var/aptg nfs rw,vers=3,rsize=1048576,wsize=1048576,soft,proto=tcp,timeo=600,retrans=2,sec=sys,addr=10.1.213.83 0 0

Now I'm really confused because I thought /proc/mounts is the most accurate place to monitor current mounts stat.
How can same mount points co-exists in /proc/mounts? what does that mean? which set of options is applied currently?

Are you confused by the defaults for unspecified parameters?

You show that the filesystem was mount with "rw,bg,soft", and that is exactly what is shown in your list of /proc/mounts.

rw - you wanted read write, you got rw.
bg - is an option to the mount, not the filesystem.
soft - that is an error recovery option for the client (hard is the default).

The only option shown that is different is the hard/soft option. Mounting hard is a reliability issue as it guarantees that a write will complete. Mounting soft allows for interrupting what would normally be an uninterruptable wait, but it also allows for data corruption. Everything else is default values.

As to "mount point busy" depends on matching what you want against what is already done. That is up to the mount command, not the filesystem. It used to be more rigid that one and only one mount can be done on a mount point - but with bind mounts, union mounts, and others, the restriction on mounts has been relaxed. It seems to only report "busy" when the entire option list matches what has already been mounted - thus a mount is redundant. If you want to remount a filesystem, use -o remount. The mount command will then dismount the filesystem and mount it again, using the new parameters. (granted, that might be counted as an error - for fun try mounting a third time with the original parameters and see if it is rejected. If it is accepted, I think that really counts as a bug).

As a side note, I suspect the rsize/wsize parameters are coming from the server (it is a MB size, which is larger than any network parameters for NFS, so I suspect the server is providing the parameters from its own filesystem which may be a raid stripe size). The timeout value is a default, and the retransmit value may be a default (I thought it was 5, but that might be for UDP instead of TCP). The security option is specified by the server.

Thanks for your advices, jpollard
But sorry if I didn't get any of your points.

I'm confused why a single mount point can be mounted with different options in /proc/mounts.
If, as you said, this is possible with bind mounts or union mounts,
then which set of options applied when accessing NFS(e.g. list a folder on NFS)?

I further tested -o remount but got yet another confusing result.
"mount -o remount ..." several times with different option values
This time no error message at all, infact no output at all
The mount options in /proc/mounts remained the same but I can see my last remount options in /etc/mtab
I am losing my confidence in /proc/mounts ...
Is /proc/mounts really the right place where kernal puts its up-to-date mount info? I just have to sure about it

And about the mount options I gave in previous posts
Those are options on my customer's production server
I too can not understand why they were set that way
Googled for default rsize/wsize, it's about 8K, far more smaller than 1MB, and retrans default 3

As to my very first question,
I guess I'll never find out why the options being overrided after system startup
I've checked dmesg and user history, no suspicious mount executed, don't know where-else can look up for mount logs

You will have to study more about how NFS works.

A number of options are specified by the server and can limit what the client can do.