🚀 go-pugleaf

In article <2497@suned1.UUCP> efb@suned1.navy.mil (Everett F. Batey II) writes:
> The main server for this client is a 4.0.3 server,
> though my work space is on a 3.3 Sun OS 3/160 server. 
> This is also where the clients get /var/spool/mail
> ( nfs,hard,intr .. rw ).

> The bad part is unlike a few weeks ago .. ucb mail ..
> Sunview mail both work very fast .. often I am frozen
> 15min to two hours waiting from the initial header until
> the curses display of all the mail messages.  Same for

You're actually waiting that long? :-)  I only have one idea about
what could be happening.  file locking.  Mush now takes
great lengths to lock mail files.  With NFS and mail existing on
a shared partition, sun's mail programs have obviously been modified
to do something "new" with respect to file locking.  The only way
to find out if this is the problem is to comment out all the "locking"
functions that mush uses (see lock.c).  For sun's, that will be "flock()"
calls.  Also, don't define DOT_LOCK.

this is not a solution!  This is a recommendation to see if the problem
(which I assume may be reliably reproduced) goes away.  If so, then we
need to investigate alternatives.  I think there is a nfs-locking func
that may be used, but don't know anything about it yet.  Let's go
from here.

IF there are any people w/suns out there who are using the same
configuration and/or environment described here, please speak up
whether youare having the problem or not.

dan <island!argv@sun.com>
-----
My postings reflect my opinion only -- not the opinion of any company.