Mail not delivered in MMDF Mail under SCO UNIX

David S. Herron david at twg.com
Sun Jul 15 12:19:40 AEST 1990


In article <678 at mecky.UUCP> walter at mecky.UUCP (Walter Mecky) writes:
>Anybody using the MMDF mail system is missing mail ? Then
>read this.


>In the last few month, from time to time I missed some mail.
>But I supposed it will be lost on the long way to my system.
>By accident (I read an article here with "cleanque" dumping
>core and tried it), I found some 50 mails from the last months
>laying in the MMDF directory and not delivered to my users.
...
>sends only _one_ mail to walter, if "file" is bigger than 10KB approx.
>The reason is the "deliver" command, which has some lock problem, if
>another "deliver" process is running at the same time. The result
>is, that "deliver" leaves the workfiles in the MMDF directories
>forever. I did never run "cleanque" (shame on me) an so the mails
>were never deliverd.

All this is the way it is supposed to work..

This "lock problem" you mention is not a problem at all.  What would
happen if you had two processes scribbling mail into your mailbox
at once?  Why, confusion, that's what!  In order to avoid the confusion
MMDF locks the mailbox while it's writing to it.  Similarly, the local
channel gives up when it can't get the lock on the mailbox.  The way
in which it gives up leaves the message in the queue directory.

The assumption is that you'll be running your system reasonably and
have background deliver's doing the delivery.  You can run channels
with mod=imm (like you mention below) and things will usually be delivered
immediately.  Then if you leave a deliver in the background it will 
catch anything which doesn't get the immediate delivery.


>My workaround is to change the "mod=imm" to "mod=reg" in the mmdftailor
>file for the local channel and run "deliver" as a background daemon. 
>Annoying is, that the original mmdftailor file has "mod=imm" for the
>local channel as it is printed in the manual. Amusing is the note in
>the SLS 162 docu from SCO: "You cannot reliably run two deliver daemons
>on the same channel simultaneously. Doing so will cause some mail to be
>sent multiple times." [ I would have been _very_ glad if this happend,
>but on my system some mail was sent zero times! ]

Good!  You read the manual and found the right way to run it!

You don't need to set mod=reg if you don't want to.  Doing so will only
stop the immediate delivery attempt.  If you leave it as mod=imm then
an immediate delivery attempt will happen and work frequently.  Leave
the background deliver in the system and it'll catch everything that falls
through the cracks.

Interesting about the multiple delivery warning.  The only time I've
seen that is on the MMDF I left at the U of Kentucky which has
a bug in the locking code.  That's a test version and the locking
code running there runs nowhere else and I haven't given it to anybody
else (particularly SCO).  Hmm.. perhaps that problem is in other
parts of the code and I didn't know it?

-- 
<- David Herron, an MMDF weenie, <david at twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david at ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!



More information about the Comp.unix.i386 mailing list