I am running a master backend and a frontend only setup on 6.03 and have NFS running fine on my backend machine. I am trying to get NFS running on my frontend machine because I use that one for backups. All of this has been working for years on the old Knoppmyth setup. The problem is with autostarting NFS on the frontend. It is setup exactly the same as the backend. I see no errors in any logs (var/log). I get the following when I run rcpinfo. NFS is not running...

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 43947 status
100024 1 tcp 41790 status
100021 1 udp 38495 nlockmgr
100021 3 udp 38495 nlockmgr
100021 4 udp 38495 nlockmgr
100021 1 tcp 38299 nlockmgr
100021 3 tcp 38299 nlockmgr
100021 4 tcp 38299 nlockmgr


I am able to start it manually (/etc/rc.d/nfslock start; /etc/rc.d/nfsd start). Then rcpinfo shows:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 38495 nlockmgr
100021 3 udp 38495 nlockmgr
100021 4 udp 38495 nlockmgr
100021 1 tcp 38299 nlockmgr
100021 3 tcp 38299 nlockmgr
100021 4 tcp 38299 nlockmgr
100024 1 udp 40319 status
100024 1 tcp 59044 status
100005 3 udp 52890 mountd
100005 3 tcp 40974 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs

Now I am able to connect... And it will stay connected until a reboot. I suspect it is a timing problem of some sort but am unsure where to look for clues. I believe that linHES does not use rc.conf daemon list for autostart (uses /var/service I think). So how does one control the timing of what starts first?

I believe the following should help:

_________________
Mike
My Hardware Profile

Thanks Mike... I tried that but found that there is an intermittent timing problem (nfslock should start before nfsd... Also netfs was already in /var/service).

My solution was to use runit (added nfslock and nfsd to 1.local) - works perfectly every time now (rebooted 20 times to confirm...)

Interesting. If you can help debug this, please try this:

Comment out your new lines in 1.local. Take a look at /etc/sv/netfs/run

Edit this file to look like this:


Does that help?

_________________
Mike
My Hardware Profile

That seems to work. I made the change to one frontend and left the other with the changes I made (runit). So far, after several reboots, it continues to work. I will leave it this way for a few days and report back.

Thanks.

Mike,

I have tested your idea for a few days and it seems to work. The actual change to /etc/sv/netfs/run is below (portmap and nfslock are in /etc/rc.d/ - "sv" doesn't work).

#!/bin/sh
exec 2>&1
/etc/rc.d/portmap start
sleep 5
/etc/rc.d/nfslock start
sleep 5
/etc/rc.d/netfs start

Thanks for the hint.

Did you try to:



I have both portmap and nfslock under /etc/sv. It may just be a matter of adding the symlinks to allow them to start (add_service.sh makes the symlinks to /var/service). You really should not have to muck with rc.d (although I'm aware some run scripts do call rc.d). NFS is a very common feature and it should "just work" provided the starup links exist.

_________________
Mike
My Hardware Profile

Both portmap and nfslock are there (in /var/service). I even removed them and "sudo add_service.sh" them back. Now, what I don't know, is there any issue with the order in which you issue the commands (ie timing issue for startup)?

The problem I am seeing is somewhat intermittent but consistent and repeatable once it hits. I have built two other test machines and, out of the box, am seing this issue. The real odd thing is that I don't see it on my backend machine (which of course is the one where most people will use NFS) - only on my frontend-only machines. I have not torn them apart enough to know if there is anything unique about the builds that would cause this to happen. I can say that by adding the rc.d start commands the problem seems to have disappeared.

More testing....

But are they in /etc/sv ? All the items in /var/service are links back to the real scripts in /etc/sv. I'm guessing since add_service.sh succeeded, they are, but it wouldn't hurt to confirm


That's what the svwaitup stuff was for. What it means is "Wait for this service to be up for 3 seconds before starting service XYZ."



Yeah, that's where I run NFS on my systems. Hmmm...

_________________
Mike
My Hardware Profile

Just spoke to jams in IRC and here's why it's not working:

_________________
Mike
My Hardware Profile

OK - now I don't feel so bad. I was starting to think I didn't know what I was doing...

Oh, wait - I don't. Damn, now I feel bad again