🚀 go-pugleaf

In article <1992Aug27.185938.21422@leland.Stanford.EDU> mosedale@genome.stanford.edu (Dan Mosedale) writes:
>However, as I understand it, due to various bugs in various vendors'
>rpc.lockds, this is running the risk of getting one's mailbox
>thoroughly hosed if more than one process tries to write the mailbox
>at once.

How about, "due to various bugs in various vendors' rpc.lockds, said
vendors don't even trust them enough to use them in their own software"?
- As far as I know, neither /bin/mail nor /usr/ucb/mail in SunOS do any
lockf() etc calls, but rather rely on "traditional" Unix locking,
checking for a /var/spool/mail/user.lock file. (I verified this for
/usr/ucb/mail by using trace - it did use flock(), though...)

Of course the lockfile method doesn't really work reliably over NFS
either (but probably better than rpc.lockd:-) - nevertheless, for what
it's worth, I have never heard of anyone getting bitten by this, and
NFS-mounting /var/spool/mail is just about the norm around here (as is
SunOS) - of course the probability of clashes depends on how much mail
you're getting.

The risk is presumably further reduced by keeping time well in sync
between server and client (we use NTP), and by mounting /var/spool/mail
with the 'noac' option. And of course *delivery* of mail should be on
the server only.

--Per Hedeland
per@erix.ericsson.se  or
per%erix.ericsson.se@sunic.sunet.se  or
...uunet!erix.ericsson.se!per

>>>>> Regarding Re: Frequency of NFS lock problems w/ NFS mounted mail spool; karl@ddsw1.mcs.com (Karl Denninger) adds:


Karl> It is decidedly NOT a good idea to have more than one machine on an
Karl> NFS-mounted mail spool writing >inbound< messages to a user's mailbox.  
Karl> The various rpc.lockd bugs will bite you if you try this, and Sun has one of
Karl> the worst records in this area.  The results are hung sendmail processes and
Karl> mail that never gets delivered.

We have a network of more than a hundred Sun4, which all mount the
mail-directory read-write and do local mail-delivery without
forwarding to the server ( it would most likely break down if they
did), and we never had serious problems  with this policy.

Karl> Then again, this is not a difficult problem to solve -- just have all hosts
Karl> forward mail for local delivery to the host which actually has the disk
Karl> attached to it, and do the mailbox delivery there.  This is a safe and sane
Karl> approach.  It also permits simple "domain hiding" if you wish to do it.

Good Bye

Linda Floren
(linda@uni-paderborn.de)

In article <LINDA.92Sep1135545@matisse.uni-paderborn.de> linda@uni-paderborn.de (Linda Floren) writes:

   >>>>> Regarding Re: Frequency of NFS lock problems w/ NFS mounted mail spool; karl@ddsw1.mcs.com (Karl Denninger) adds:

   Karl> It is decidedly NOT a good idea to have more than one machine on an
   Karl> NFS-mounted mail spool writing >inbound< messages to a user's mailbox.  
   Karl> The various rpc.lockd bugs will bite you if you try this, and Sun has one of
   Karl> the worst records in this area.  The results are hung sendmail processes and
   Karl> mail that never gets delivered.

   We have a network of more than a hundred Sun4, which all mount the
   mail-directory read-write and do local mail-delivery without
   forwarding to the server ( it would most likely break down if they
   did), and we never had serious problems  with this policy.

We have over 350 client workstations (half Suns, half IBMs) mounting a
single mail directory (from a Sun) read-write, and all of them forward
mail to the server for local delivery.  This machine is also used as a
forwarding machine for mail that goes off campus.  It has not broken
down yet (but we have been seeing some high loads lately).

We have definitely seen locking problems between IBM RS6000 NFS
clients and our Sun4 NFS server.  We have received patched rpc.lockd,
and a new kernel with the NFS jumbo patch, but still we have been
having problems with a user on an IBM NFS client typing "q" to get out
of mail, and the process never returns.  Killing and restarting
rpc.lockd sometimes works to free up these processes that are waiting
for locks from the server, but something only a fastboot of the server
will fix it.  It had been working fine for several months (the "q" bug
had disappeared), so we are not sure why it has come up again now.

I will say that we have doing this for several years (since 1987) with a
network of Suns, and we never had this problem until we added IBM
RS6000 NFS clients into the mix.  It still has been a relatively
stable mail architecture for quite a few machines.

Now, however, in the face of such high loads, and the number of client
workstations increasing, we are working on moving to a solution based
on POP, which we hope will allow us to split the load across two or
more server machines (you can't split one directory across two NFS
servers easily).

If you want more info, send me email.
--
Jim Ault, ITS Systems Programmer, aultj@rpi.edu    <><

In article <vanepp.715392389@sfu.ca> vanepp@fraser.sfu.ca (Peter Van Epp) writes:
>As I recall (it has been about a year since I was through this) Elm uses flock()not lockf(), so NFS locking isn't a problem (nor possible for that matter since
>flock() won't work on an NFS file), what does the locking is the .lock file that

This is true on SunOS but not AIX v3.  AIX v3 does support flock over NFS.

Marc


-- 
Marc Wiz			Yes that really is my last name.
MaBell:				(512)244-8780
Internet:			mwiz@mpd.tandem.com
The views expressed are my own.  Mine all mine!