Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.unix.i386 Subject: Re: Mail not delivered in MMDF Mail under SCO UNIX Keywords: MMDF SCO-UNIX deliver Message-ID: <7590@gollum.twg.com> Date: 15 Jul 90 02:19:40 GMT References: <678@mecky.UUCP> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 63 In article <678@mecky.UUCP> walter@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, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!