home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.hp:10123 comp.unix.questions:10790 comp.unix.wizards:3823 comp.unix.admin:4913 comp.mail.uucp:1757 comp.mail.misc:2933
- Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!klaava!hkarhune
- 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
- Message-ID: <HKARHUNE.92Sep7102237@hydra.Helsinki.FI>
- Date: 7 Sep 92 08:22:37 GMT
- References: <1992Sep6.155328.11649@aruba.uucp>
- Sender: news@klaava.Helsinki.FI (Uutis Ankka)
- Organization: Department of Theoretical Physics, University of Helsinki,
- Finland
- Lines: 108
- In-Reply-To: glenr@aruba.UUCP's message of 6 Sep 92 15: 53:28 GMT
-
- 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. |
- \-----------------------------+-----------------------------------------/
-