Well I wish to thank all who responsed to my request:
ras@unipress.com (Ray Schnitzler)
deb@beaux.atwc.teradyne.com (Deborah Heller)
wallen@cogsci.UCSD.EDU (Mark R. Wallen)
peb@sandoz.ueci.com (Paul Begley)
cyerkes@jpmorgan.com (chuck yerkes)
poc@shaddam.usb.ve (Patrick O'Callaghan)
glk@pls.amdahl.com (Greg Kastanek)
bill@access.com (Bill Hunter)
Perry_Hutchison.Portland@xerox.com (Perry Hutchison)
peter@imatron.com (Peter M. Cooke)
nolfb@jcdbs.2000.disa.mil (Bill Nolf)
erzmann@irb.uni-hannover.de (Andreas Erzmann)
ballisti@ifh.ee.ethz.ch (Raymond Ballisti)
eckhard@ts.go.dlr.de (Eckhard Rueggeberg)
winters@ct.med.ge.com (Steve Winters)
The question I was looking for help on:
>My question is, without providing the users the ability to run umount, is there
>a clean way to ensure that the server will not try to inform the down systems
>that it is back up?
The following are the suggestions I received:
1) Provide a program that performs the umount -a then the shutdown command.
2) Maybe try automount.
3) Use sudo to allow the users to run umount.
4) To get rid of the statd messages, clean out the directory /etc/sm.bak,
removing the names of workstations you don't want statd to know about.
Then kill and restart, statd.
5) You could try clearing (not deleting) /etc/rmtab while booting.
6) We sometime experience the same problem (ie file servers complaining about
"fcntl: statd " errors, etc.) when similar shutdown's occur. We've
been successful by simply adding a line to /etc/rc.local (or rc.boot, I don't
remember) that recursively removes the /etc/sm and /etc/sm.bak directories
BEFORE rpc.lockd and rpc.statd daemons are started.
The solution I plan on implementing, since I feel it will be the cleanest is
a modified version of 4 and 6.
A cron job will execute on the server every x minutes and will status every
system which has a file system mounted. If the queried system does not
respond it will be place in a list of unresponding systems. If the system does
not respond twice, then it will be removed from the /etc/rmtab, /etc/sm, and
/etc/sm.bak directories. After the removal of the system in.statd will be
restarted to ensure that the "rpc statd" error goes away. This may cause
some "rpc statd" messages to be displayed, but it will ensure that a temp.
network glich doesn't cause the entries in the server tables from being
removed.
If there is interest I'll either e-mail to those who want the developed code
or post if enough interest deems it.
Craig
-- =============================================================================== = Craig Gates cgates@fnoc.navy.mil = = (408)656-4597 = ===============================================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:35 CDT