VectorLinux
August 30, 2014, 04:11:34 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1]
  Print  
Author Topic: Correct way to start daemons for nfs  (Read 2142 times)
sparkyhall
Vectorite
***
Posts: 118


« on: March 19, 2009, 12:31:13 pm »

I followed the excellent how to from Granny Geek http://forum.vectorlinux.com/index.php?topic=669.0 to setup my network shares using nfs. All went well until I reached the bit that says "Finally, go to /etc/rc.d/ and make rc.nfsd executable. That should start up the nfs networking at boot." well my /etc/rc.d/rc.nfsd was already executable and re-booting stops my shares from working. Issuing various ps aux | grep commands reveals that after a re-boot portmap is running but nfsd, mountd, statd and rquotad are not so it seems that rc.nfsd is not run. By the way if I issue /etc/rc.d/rc.nfsd start as root every thing starts as expected. I've tried sellecting portmap in vasm but that only starts portmap, mountd and nfsd but not statd and rquotad.

I can find various ways of starting the services but I feel I'm missing something obvious so could someone please explain how these services should be started automatically.

Thanks,

Chris
Logged
GrannyGeek
Packager
Vectorian
****
Posts: 2567


« Reply #1 on: March 19, 2009, 08:55:57 pm »

Chris,
Where on that link do you find "go to /etc/rc.d/ and make rc.nfsd executable"? I did a search on the page and couldn't find anything about making rc.nfsd executable. Are you perhaps looking at an old copy that you saved in the past? Things have changed since I wrote that originally, and since the necessary files are included and ready to go, you shouldn't have to do anything with rc.nfsd. I revised the how-to a while ago to reflect the present situation with VectorLinux.

I have set up an nfs network for my three Linux systems numerous times as I've tested betas and release candidates and it always works for me.

Follow the steps in the how-to to the point where you have edited the necessary files in /etc and have created your mount-point directories in /mnt. Then you run a series of commands as root in this order:
# rpc.portmap
# rpc.mountd
# rpc.nfsd
# rpc.statd
# rpc.rquotad
# exportfs -a

When you've done these steps on all computers you're including in your home network, you should be able to do a
mount /mnt/networkedcomputer
substituting the actual name of the directory that is the mount point for the computer you want to have available on your network. I hope you understand what I mean.

You should have portmap selected in VASM under Services for your runlevel.

Once I run those commands, my nfs network is running. However, I don't automount the networked computers. I've never tried to do that, so I don't know how it works if you do choose to automount an nfs share at startup. I do a mount /mnt/networkedcomputer command when I want to have access to one or more computers on my network. I also use fixed IP addresses, as I explain in the how-to. I find it easier because the computer IP addresses shouldn't change.

The lines in my /etc/fstab under # NFS file systems are:
compaq:/   /mnt/compaq   nfs  users,noauto  0 0
hall:/    /mnt/hall    nfs  users,noauto  0 0

That is on the computer I'm writing this on (Gateway). If I were using compaq, the lines in /etc/fstab would be:
Gateway:/   /mnt/Gateway   nfs  users,noauto  0 0
hall:/    /mnt/hall    nfs  users,noauto  0 0

I have not had to do anything with files in /etc/rc.d for a very long time. All I can tell you is that once I run the series of commands described above beginning with rpc.portmap and ending with exportfs -a, I can mount my nfs shares every time without running the commands again.

If you find that
/etc/rc.d/rc.nfsd start
always gets things going for you, you can put that command in /etc/rc.d/rc.local and it should run automatically as VL starts up.
--GrannyGeek
Logged

Registered Linux User #397786

Happily running VL 7 Gold on  a Sempron LE-1300 desktop (2.3 GHz), 4 G RAM,  GeForce 6150 SE onboard graphics and on an HP Pavilion dv7 i7, 6 gigs, Intel 2nd Generation Integrated Graphics Controller
sparkyhall
Vectorite
***
Posts: 118


« Reply #2 on: March 20, 2009, 09:48:25 am »

Where on that link do you find "go to /etc/rc.d/ and make rc.nfsd executable"? I did a search on the page and couldn't find anything about making rc.nfsd executable. Are you perhaps looking at an old copy that you saved in the past?

Yes I was refering to a local copy I saved a while ago, sorry. Embarrassed


You should have portmap selected in VASM under Services for your runlevel.
Once I run those commands, my nfs network is running.

My nfs shares also work after following your guide and enabling protmap in vasm, however my concern is that enabling portmap in vasm doesn't start rpc.statd or rpc.rquotad after a restart and according to the rpc.statd man page it looks kind of important. I quote "It is used by the NFS file locking service, rpc.lockd, to implement lock recovery when the NFS server machine crashes and reboots". Also the script rc.rpc that is called by /etc/rc.d/rc.nfsd to start rps.statd states "You must run these daemons in order to mount NFS partitions (unless you use the mount option '-o nolock', which can corrupt files and is not generally recommended unless you are mounting the partition(s) as read-only)" and "To run an NFS server, starting these is mandatory".

Perhaps I'm reading too much into this and this funtion is now incorporated into the kernel or it doesn't matter with journal file systems. It would be nice to see an explination somewhere though.

Oh thank's for the reply by the way,

Chris
Logged
GrannyGeek
Packager
Vectorian
****
Posts: 2567


« Reply #3 on: March 20, 2009, 05:27:06 pm »

I am no expert on nfs or anything else, for that matter. I just know what works for me.

I've been using nfs for networking my Linux computers for several years. I've never had any file corruption or any problems of any kind.

I don't know much about file locking. I'm not even sure what it means. I think one meaning is that if a file is open, it can't be written to by some other user on the network while I have it open. On my network, I'm the only user so preventing some other user from writing to the same open file will never be an issue. I also know from experience with Firefox that if the program locks up, the files that were open for that profile are locked and as far as the program is concerned, that user is still using Firefox. So if you (that user) try to restart it, it'll tell you that you need to use another profile. You can get rid of that message by deleting the locked file in your home directory for Firefox.

Experience casts doubt on these statements:
"You must run these daemons in order to mount NFS partitions (unless you use the mount option '-o nolock', which can corrupt files and is not generally recommended unless you are mounting the partition(s) as read-only)" and "To run an NFS server, starting these is mandatory". If this were true, I couldn't mount my nfs partitions, but I can--easily and every time. I don't know much about servers, but I assume that when the computer I'm at connects to another computer on my network, the computer I'm at is functioning as a server. If the computer I'm at sends a file to another computer on the nfs network, it's a server. So whatever is needed must be starting.

I edit files on the mounted shares frequently and have never had even a hint of a problem. My suggestion is to follow the procedure I described and if you can mount your shares and transfer files successfully, don't worry about it.

If anyone reading this has other advice, please do post it.
--GrannyGeek
Logged

Registered Linux User #397786

Happily running VL 7 Gold on  a Sempron LE-1300 desktop (2.3 GHz), 4 G RAM,  GeForce 6150 SE onboard graphics and on an HP Pavilion dv7 i7, 6 gigs, Intel 2nd Generation Integrated Graphics Controller
sparkyhall
Vectorite
***
Posts: 118


« Reply #4 on: March 21, 2009, 02:26:06 pm »


I've been using nfs for networking my Linux computers for several years. I've never had any file corruption or any problems of any kind.

I edit files on the mounted shares frequently and have never had even a hint of a problem. My suggestion is to follow the procedure I described and if you can mount your shares and transfer files successfully, don't worry about it.

It's comforting to know that nfs works reliably with just portmap enabled in vasm. Time permitting I may try exprimenting by re-booting my server mid file transfer with and without rpc.statd to see what happens, although either way I won't be surprised if I end up with a currupt file. I guess for home use the demands on the network are significantly less so perhaps some of the safeguards are simply not needed.

Once again thanks for the response,

Chris
Logged
GrannyGeek
Packager
Vectorian
****
Posts: 2567


« Reply #5 on: March 21, 2009, 09:35:44 pm »

I guess for home use the demands on the network are significantly less so perhaps some of the safeguards are simply not needed.

That is my feeling. I expect that a power failure during an nfs file operation might corrupt the file(s), but all my computers are plugged into uninterruptible power supplies and I would have enough time to do an orderly shutdown.

If you do your experiment, let us know the result.
--GrannyGeek
Logged

Registered Linux User #397786

Happily running VL 7 Gold on  a Sempron LE-1300 desktop (2.3 GHz), 4 G RAM,  GeForce 6150 SE onboard graphics and on an HP Pavilion dv7 i7, 6 gigs, Intel 2nd Generation Integrated Graphics Controller
rbistolfi
Packager
Vectorian
****
Posts: 2282


« Reply #6 on: March 21, 2009, 09:45:10 pm »

If you need to run commands at boot time, the best place would be /etc/rc.d/rc.local, I dunno if it is what are you looking dor but if you append, for example:

Code:
sh /etc/rc.d/rc.nfsd start

to that file, the service will be started every boot.

HTH
« Last Edit: March 21, 2009, 09:47:07 pm by rbistolfi » Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."
Jorge Luis Borges, Avatars of the Tortoise.

--
Jumalauta!!
sparkyhall
Vectorite
***
Posts: 118


« Reply #7 on: March 23, 2009, 01:47:03 pm »

Well I've completed my tests using different nfs settings and  I can say that I'm rather impressed.

My set-up for the tests includes my main PC which has VL6.0 DLX and is configured to be the client by simply placing an nfs entry in fstab as per GrannyGeeks instructions. For the server I used an old Pentium 3 750MHz box with a 10Mbit NIC with VL6.0 STD installed. All the test were conducted using a single large file, in this case the VL6.0 DLX iso, which coupled with the limited network speed gave me around 10 minutes to pluck up the courage to re-boot the server mid transfer. So on to the results:

Server set-up following GrannyGeeks guide i.e edit hosts, exports and enable portmap in vasm (portmap, mountd and nfsd running).

  • Copy file from client to server using Thunar, reboot server, client eventually flags permission denied error and leaves a partially copied file on the server. I tried this 3 times to make sure.
  • Copy file from client to server using pcmanfm, reboot server, client eventually flags permission denied error and leaves a partially copied file on the server.
  • Copy file from client to server using cli, reboot server, client eventually flags permission denied error and leaves a partially copied file on the server.

Server set-up as before but with portmap in vasm disabled and rc.local modified to include "/etc/rc.d/rc.nfsd start" (portmap, mountd, nfsd, statd and rquotad running).

  • Copy file from client to server using Thunar, reboot server, after a minute or so file transfer resumes. I tried this 3 times + 1 transfer with 2 re-boots and another where I simply pulled the power cord out of the server. Grin
  • Copy file from client to server using pcmanfm, reboot server, after a minute or so file transfer resumes.
  • Copy file from client to server using cli, reboot server, after a minute or so file transfer resumes. I tried this 2 times one of which I left the server off for 45 minutes and still the transfer resumed when the server was turned back on.

Conclusion
For a home network either method of starting nfs should be fine as you are likely to be in control of both client and server and therefore unlikely to loose any data. For business use it's probably best to play it safe and start nfs using rc.nfsd.

For my own use I rather like the idea that a file transfer resumes if interrupted so I think I will start nfs with rc.nfsd for the time being with a view to creating my own modified nfs start-up script later on. The reason for the modified nfs start script is that rc.nfsd starts 8 nfsd threads which seem overkill for home network. It also starts rquotad for disk quota allocation which is something I simply don't need.

Chris
Logged
GrannyGeek
Packager
Vectorian
****
Posts: 2567


« Reply #8 on: March 23, 2009, 06:05:55 pm »

Thanks for doing the testing and reporting results. I wonder if these should go in the HowTo for an nfs home network.
--GrannyGeek
Logged

Registered Linux User #397786

Happily running VL 7 Gold on  a Sempron LE-1300 desktop (2.3 GHz), 4 G RAM,  GeForce 6150 SE onboard graphics and on an HP Pavilion dv7 i7, 6 gigs, Intel 2nd Generation Integrated Graphics Controller
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!