walter@mecky.UUCP (Walter Mecky) (07/07/90)
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. It was rather annoying, because in most cases I did not know about the mail and thought "Ok, I asked something and he didn't answer". I did not notice the problem earlier, because most of the mail was delivered fine! And it was not a problem of adressing but of a runtime hazard in the MMDF mail system. I can reproduce the error with this commands: for i in 1 2 do mail walter <file done 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. 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! ] Anybody out there who can confirm those things ? -- Walter Mecky [ walter@mecky or ...uunet!unido!mecky!walter ]
david@twg.com (David S. Herron) (07/15/90)
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, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
shwake@raysnec.UUCP (Ray Shwake) (07/16/90)
In article <7590@gollum.twg.com> david@twg.com (David S. Herron) writes: > >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. As I've already pointed out to David (Hi, guy!) having deliver run as a background daemon still doesn't guarantee that the message will finally be delivered. I know. Every few days I find orphaned files in mmdf/lock/home. The need to lock the destination box is obvious. But it's dis- heartening to work with a system that can't properly post more than one message to a single box in rapid succession. The sdaemon I use (and its rmail variant) test for the presence of a lock file for ten seconds at one second intervals. Yet it posts so quickly I've YET to trip it up.
walter@mecky.UUCP (Walter Mecky) (07/21/90)
In article <7590@gollum.twg.com> david@twg.com (David S. Herron) writes: < In article <678@mecky.UUCP> walter@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@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@mecky.uucp or ...uunet!unido!mecky!walter ]