Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!turnpike!argv From: argv%turnpike@Sun.COM (Dan Heller) Newsgroups: comp.mail.mush Subject: Re: Suddenly we hang in Mush 6.4 Message-ID: <126231@sun.Eng.Sun.COM> Date: 12 Oct 89 17:46:39 GMT References: <2497@suned1.UUCP> Sender: news@sun.Eng.Sun.COM Reply-To: argv@sun.UUCP (Dan Heller) Distribution: na Lines: 33 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 ----- My postings reflect my opinion only -- not the opinion of any company.