From: hkarhune@hydra.Helsinki.FI (Heikki Karhunen)
Newsgroups: comp.sys.hp,comp.unix.questions,comp.unix.wizards,comp.unix.admin,comp.mail.uucp,comp.mail.misc
Subject: Re: /usr/mail/glenr.lock not creatable after 10 tries
Date: 7 Sep 92 08:22:37 GMT
Organization: Department of Theoretical Physics, University of Helsinki,
	Finland

In article <1992Sep6.155328.11649@aruba.uucp> glenr@aruba.UUCP (Glen Reesor) wrote:
> I'm using the ftpmail server at decwrl.  When I request large files it usually
> takes a few tries to get all parts.  Up until now I just thought that some
> site along the way was dropping them.  But the other day I noticed a number
> of bounced messages going *back* to decwrl, so it appears that it is
> *my* site dropping parts.  My system configuration is:
> 
> Network of HP9000/730's running HPUX 8.07.  All machines share a single
> /usr/mail directory using NFS.  The machine that /usr/mail actually resides
> on is our UUCP machine.  My account is not on the UUCP machine, thus the mail
> will be routed from the UUCP machine to my machine using SMTP.
> 
> I've configured sendmail to mail a copy of all bounced headers to postmaster,
> and this is what I get:
> 
> --------------------------------------cut--------------------------------------
> From MAILER-DAEMON@onyx Sat Sep  5 21:27 EDT 1992
> Received: from ruby by onyx with SMTP
>         (16.8/16.2) id AB20350; Sat, 5 Sep 92 21:26:49 -0400
> Date: Sat, 5 Sep 92 13:32:58 -0700
> From: Mail Delivery Subsystem <MAILER-DAEMON@onyx>
> Return-Path: <MAILER-DAEMON@onyx>
> Subject: Returned mail: Can't create output
> To: Postmaster@onyx
> Status: RO
> 
>    ----- Transcript of session follows -----
> mail: /usr/mail/glenr.lock not creatable after 10 tries
> 550 <glenr@onyx>... Can't create output
> 
>   ----- Message header follows -----
> --------------------------------------cut--------------------------------------
> 
> onyx is the machine that my account is on and ruby is the UUCP machine.  I've
> RTFM'ed and can't find any reference to "Can't create output".  Since I don't
> understand the in's and out's of mail lock files all I can postulate is that
> more than one piece of mail is trying to be delivered at once.  This 
> particular mail bounced on Saturday in the evening, so there was no mail
> other than from decwrl coming to me.
> 
> So.....is it a problem with NFS mounting /usr/mail?  Or is sendmail tripping
> over itself because of the volume of mail coming to me all at once?

This sounds very similar to one problem I had this summer. And no, I
didn't find any solution to it, but here is what I discovered.

We have at work several Apollos that co-exist very nicely with each
other. Now, we got a HP 9000/710 on loan from HP (they obviously
wanted us to buy it, but that is another story altogether).

My home directory is in Apollo, but I mainly used the HP, because I
was supposed to try it out and to see that it too co-existed with the
rest of the boat anchors hanging around the net.

As the only way to share HP-UXen and Apollo's filesystem is via NFS,
that is exactly what we did (by the way, we run Domain/OS 10.4 on the
Apollos with NFS 2.3 and the HP-UX was around 8.07).

I configured my own environment so that my home directory (among other
things) was mounted via NFS from the Apollo cluster. I also mounted
HP's /usr/mail to our mail handling Apollo's /usr/spool/mail.

Now begins the fun part. I could use Elm (2.3 PL11, not the one HP
supplies as I use Elm 2.3 in Apollos too and HP's Elm didn't
understand all the elmrc switchery) in HP to read and send my mail.
But.  Whenever I logged in as root (or even a normal user), I had to
wait about 20 seconds after the copyright texts while mail was
checking whether I had any mail. It invariably failed with: 'mail:
can't lock /usr/mail/<username> after 10 tries'.

I digged around this for a while, and it seems that mail (when invoked
with -e or otherwise) creates a lock file, /usr/mail/<username>.lock
in the mail directory. For some reason it couldn't create one when the
/usr/mail was NFS mounted from Apollo.

Actually, it _did_ create something... Namely a file called
/usr/mail/root.lock, the length of which was 0 and all the protection
bits were clear. I tested Apollo's mail (the sys5.3 variety) and its'
lockfile was some bytes long and its' protection was r+w for owner (I
think, not sure about this anymore :) ).

I had more or less synchronized the GIDs and UIDs in both machines (I
didn't do 'em all, the HP was on loan, after all...) and the NFS
mounting was done with default options.

I _know_ that Apollo's NFS 2.3 is not fully functional (lacks lockd
among other things) and HP will ship version 3.0 anytime-real-soon-now, 
but by the previous problem the glitch might be in HP's NFS. Comments?

> 
> If I can get this worked out, FTP mail may actually be semi-painless!  Any
> suggestions or solutions would be greatly appreciated.  
> 
> Please e-mail.  I will summarize if there is interest.

Hope someone can unravel this... I'd sure like to know how...

> 
> -- 
> Glen Reesor                       |Internet Style: aruba!glenr@uu2.psi.com
> Systems Administrator, Project Zed|UUCP     : ...!uunet!uu2.psi.com!aruba!glenr

	Heikki Karhunen

/-----------------------------+-----------------------------------------\
| hkarhune@hydra.helsinki.fi  | There is always a job for a theoretical |
| Heikki.Karhunen@helsinki.fi | physicist -- at least in theory.        |
\-----------------------------+-----------------------------------------/
Newsgroups: comp.sys.hp