Mail not delivered in MMDF Mail under SCO UNIX
Walter Mecky
walter at mecky.UUCP
Sat Jul 21 11:46:58 AEST 1990
In article <7590 at gollum.twg.com> david at twg.com (David S. Herron) writes:
< In article <678 at mecky.UUCP> walter at mecky.UUCP (Walter Mecky) writes:
< >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.
< ...
< 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.
It _would_ be no great problem, if the manual would mention it. But
in any case this is a bad dessign. Better would be an automatic waiting
of the local channel for the mailbox getting free. Best would be a
queued access to the mailbox by a seperate process. Giving up by the
local channel should only be done when the next invokation looks for
undelivered messages.
<
< The assumption is that you'll be running your system reasonably and
< have background deliver's doing the delivery.
My assumption is that this should have been written in the manual.
< Good! You read the manual and found the right way to run it!
No good! I missed mail over a period of some months and noticed it only
by accident. Then I read the manual and found a workaround. Better than
nothing, ok.
< >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.
< 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.
Wrong in SCO UNIX! See the note to SLS 162, Page 4: "You cannot run a
deliver -b on a channel that has mod=imm set for that channel ...This is
a known problem and will be fixed in a future release."
< <- David Herron, an MMDF weenie, <david at twg.com>
As a MMDF weenie you surely can tell us, if the following is no problem
too. If I send mail mail with
mail user
and log out immediatly when the shell prompt is displayed, the mail
is _not_ send. I suppose this error is caused by the hangup signal which
should be ignored in processes running asynchronesly.
--
Walter Mecky [ walter at mecky.uucp or ...uunet!unido!mecky!walter ]
More information about the Comp.unix.i386
mailing list