Original Problem:
__________________
The master NIS server is intermittently available and unavailable. One
second I can ping and mount drives from it and the next second its as if
it has dissappeared off the face of the earth.
Some PCs in a dept. would not start up PCNFS while other would start up with no
problem. Physically the network would is fine and etherfind etc. revealed
nothing but the usual traffic one would expect on a network.
Solution:
__________
Changing the server that the PCs bind to seemed to do the trick. I don't know
why this solved the problem, the server that the PCs were binding to was not
under a particularly heavy load and other PCs in the dept could bind to
"problem" server with no problem.
However, the patch 100075 was applied around the same time and may have had a
hand in the solution. However this patch is for file locking and I don't really
see how that would relate to PCNFS booting, unless it had something to do
with the way rpc calls are handled.
Thanks,
Larry Chin {larry@cch.com} CCH Canadian Ltd.
System Administrator 6 Garamond Court
Research and Development Don Mills, Ontario.
(416) 441-4001 ext. 349 M3C 1Z5
Rule 46, Oxford Union Society, London:
Any member introducing a dog into the Society's premises shall
be liable to a fine of one pound. Any animal leading a blind
person shall be deemed to be a cat.
Replies:
_________
------------------------------------------------------
> "Andrew Luebker" <aahvdl@eye.psych.umn.edu> suggested:
> setting an appropriate NETMASK for the PC-NFS microcomputers, using "net
> subnet 255.255.255.0" during bootup and making sure that the "pcnfsd" daemon
> is automatically started whenever your server reboots.
> Eckhard.Rueggeberg@ts.go.dlr.de suggested:
> Rebooting the PC helps, perhaps multiple times.
> nagel@post.inf-wiss.ivp.uni-konstanz.de
> use the $NISSERVER and $HOME feature for mounting drives, from the master.
> this feature works only with the real master and not with the slaves.
** this is interesting because the PCs were trying to bind to the master **
----------------------------------------------------
> Richard Elling <Richard.Elling@eng.auburn.edu>
> take a close look at your
> addresses. In particular, make sure you don't have duplicate IP
> addresses for any PCs. Second, check to see if you have entries in
> the ethers NIS map for any PCs. Make sure these match exactly. You
> can also use the arp command on the Suns to see what the Suns think
> the mapping is from IP address to ethernet address.
> What will happen is as a machine comes up it will send an arp packet
> which tells everyone what its IP address is. This will set up an arp
> table entry on the Suns so that the Sun will know which ethernet address
> to send packets destined for the corresponding IP address. If another
> machine speaks up and claims the IP or ethernet address, then the first
> machine will seem to disappear.
> There was some talk a while back about some Asian ethernet clone cards
> which used the same ethernet address. So be sure and check each PC
> out.
---------------------------------------------------
> Mike Raffety <miker@sbcoc.com>
> Are there blank lines in any of your NIS maps????
----------------------------------------------------
> birger@vest.sdata.no (Birger A. Wathne)
> try turning off the SQE heartbeat on the transceiver
----------------------------------------------------
> ldavis!ken@snowbird.Central.Sun.COM (Ken Cox)
> upgrading the drivers for the PC ethernet controllers and in some cases
> replacing the PC ethernet controller. The SS2 have VERY fast ethernet
> performance and it seems that some PC controllers just cannot keep up with
> the data.
Thanks also to:
geertj@ica.philips.nl (Geert Jan de Groot)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT