Why and how settings of mounting NFS in /etc/rc.local are overrided with /etc/fstab?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
/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.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...
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
# 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.
mount -t nfs -o rw,bg,soft 10.1.XXX.XXX:/volumes/nrenas_vol1/appnre /var/aptg
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.
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