Subject: Re: Pine hangs (was Re: Version 3.95 Buggy?)

From: "Randall S. Winchester" <[email-masked]>
Date: Thu, 3 Oct 1996 16:41:05 -0400

On 23 Sep 1996, R. Stewart Ellis wrote:

: Mark Crispin <[email-masked]> writes:
: 
:  >On 19 Sep 1996, Tony Fitzgerald wrote:
:  >> The problem that we are observing appears to happen to only one specific
:  >> account but has happened at least twice in the past month.  The account
:  >> appears to get a pine session into a hung state (presumably some sort of
:  >> kernel block because a kill -9 will not get rid of the process.)  This
:  >> occurs with PINE3.95 running under Solaris 2.5.  Once this account gets
:  >> into the hung state, subsequent login attempts also hang (/bin/mail -E
:  >> is run during login to check for new mail and that process also hangs
:  >> and can not be killed.)  At this time, the account has two immortal pine
:  >> processes and about a dozen /bin/mail processes and it seems only a
:  >> system re-boot will solve the problem.)
: 
: 
:  >By any chance, are any of these mail files accessed via NFS?  If so, you
:  >may be bit by a well-known bug with the fcntl() locking call; when locking
:  >over NFS, it invokes a pair of daemons called statd and lockd that are
:  >very fragile.
: 
:  >Supposedly, the code in 3.95 disables fcntl() locking if NFS is involved,
:  >but Solaris 2.5 may have cleverly broken the test that it used for NFS.

Wow it would be nice if this was better documented.

                                /* ftinode should be -1 if NFS */
  return ((!fstat (fd,&sbuf) && !ustat (sbuf.st_dev,&usbuf) &&
           !++usbuf.f_tinode) ||
          ((int) mail_parameters (NIL,GET_DISABLEFCNTLLOCK,NIL))) ? NIL :
            fcntl (fd,(operation & LOCK_NB) ? F_SETLK : F_SETLKW,&fl);

From "man ustat":

BUGS
     The NFS revision 2 protocol does not permit  the  number  of
     free  files to be provided to the client; thus, when ustat()
     is done on an NFS file system, f_tinode is always -1.

Since Solaris2.5 uses NFS V3 when it can, this test is nolonger valid.
However it concerns me that this locking is being ignored. Most vendors have
patches avaliable to fix some of the lockd/statd problems. The vendor
mailers (i.e. mailx) do not ignore these locks. Blind trust...

Randall

: 
: I am not a network expert, but in the past you have failed to take account
: of some of the special features of the Solaris environment (old header
: include kluges ~pine 3.91).  With Solaris 2.5, Sun has wisely or unwisely
: gone back to including support for some older BSD interfaces (I think they
: should have left them out).  Could any of those be fooling the tests you are
: making for fcntl()?
: 
: It might be helpful if the original poster has access to a Solaris 2.4
: machine to config and compile pine on that and see if the binary gives the
: same problems as his Sol  2.5 binary.
: 
:  >-- Mark --	Read http://www.imap.org for the "best kept secret in email"
: 
:  >DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
:  >Science does not emerge from voting, party politics, or public debate.
: 
: 
: -- 
:   R.Stewart(Stew) Ellis, Assoc.Prof., (Off)810-762-9765   ___________________
:   Humanities & Social Science,  GMI Eng.& Mgmt.Inst. ()  /   _____  ______
:   Flint, MI 48504    Free speech and free software!  /\ /        / /  /  / /
:   Web admin:  http://www.gmi.edu/      [email-masked]   /________/ /  /  / /
: 
:

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Oct 1996 20:54:27 -0700

> Wow it would be nice if this was better documented.

I would have appreciated that too.

>      is done on an NFS file system, f_tinode is always -1.

Amazing.  It actually appears in someone's man page.  I had to determine
it by experimentation and reading kernel source code.

> Since Solaris2.5 uses NFS V3 when it can, this test is nolonger valid.

I heard that from SUN.  How SUN justifies returning "number of inodes"
over a protocol that is supposed to be OS-independent is beyond me.

However, SUN also claims that all the NFS locking bugs are fixed in
Solaris 2.5, so it doesn't matter that my test doesn't work (put another
way, the test does exactly the right thing, working only on systems where
NFS is broken).

That's SUN's claim, anyway.  I don't really believe it.  The entire design
of lockd/statd is bogus, and I doubt that it can ever be made to work.

> mailers (i.e. mailx) do not ignore these locks. Blind trust...

The lock in question is not one that mailx would use.  This lock is the
private lock in the c-client library (called by Pine and imapd) that
guards against multiple Pines/imapds/etc. getting read/write access to the
same file at any one time.  As long as you use UNIX mbox format, it
doesn't matter that much if it fails.  The worst that will happen is that
if you run more than one Pine on the same mailbox, one of the Pines will
eventually cause the other to get an ACCESS ERROR.

If you use certain other formats (e.g. tenex format), it is a problem,
since these formats use random access and depend upon locking to work.
But we've always said, "don't use tenex format over NFS".

-- Mark --	Read http://www.imap.org for the "best kept secret in email"

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.