vlr@vlr@litwin.com (Vic Rice) (08/05/90)
I recently discovered a problem with my mail system. I am using SCO Opendesktop (SYSV R3.2) which uses MMDF as its MTA. My problem is with mail arriving but not being delivered. I requested a multi-part distribution from LISTSERV@vm1.nodak.edu. Several days later I received parts 1 and 10 in my mail box. Parts 2-9 never showed up. Several months later I was exploring and discovered "/usr/spool/mmdf/lock/home/msg". In this directory where many msg.* files. Parts 2-9 where in this directory. What gives ?? Is there some MMDF configuration modification I need to do ? I hasten to add this directory contained over 100 files. Are all these files pieces of mail that were never delivered ?? -- Dr. Victor L. Rice Litwin Process Automation
jbev@iscden.UUCP (J.Bevier at Home on Hipeak) (08/06/90)
In article <1990Aug05.144539.5500@vlr@litwin.com> vlr@vlr@litwin.com (Vic Rice) writes: >I recently discovered a problem with my mail system. I am using >SCO Opendesktop (SYSV R3.2) which uses MMDF as its MTA. >My problem is with mail arriving but not being delivered. I >requested a multi-part distribution from LISTSERV@vm1.nodak.edu. >Several days later I received parts 1 and 10 in my mail box. Parts >2-9 never showed up. Several months later I was exploring and discovered >"/usr/spool/mmdf/lock/home/msg". In this directory where many msg.* >files. Parts 2-9 where in this directory. What gives ?? Is there some >MMDF configuration modification I need to do ? I hasten to add this >directory contained over 100 files. Are all these files pieces of mail >that were never delivered ?? >-- >Dr. Victor L. Rice >Litwin Process Automation The general problem here is that locks are used while mail is being delivered. If a second piece of mail arrives to be delivered to a mail box being updated, it will be put in /usr/spool/mmdf/lock/home/msg.* to be delivered later. However, this can not take place unless deliver is called to deliver the mail! Either run deliver manually or put the following entry in the /etc/rc.d/7/udaemons file to have deliver run in the background. The default is every 10 minutes. I found this out about 6 months ago. It seems SCO forgot this small item. It will fix you right up. Below is the udaemons file that is updated. Also, see the man page for deliver. Enjoy, Jim Bevier jbev@iscden.uucp copy of my /etc/rc.d/7/udaemons file as modified for MMDF deliver -----------------------------file starts here---------------------- : # @(#) udaemons.sh 1.2 89/06/23 # # Copyright (C) The Santa Cruz Operation, 1985. # This Module contains Proprietary Information of # The Santa Cruz Operation, Microsoft Corporation # and AT&T, and should be treated as Confidential. # # /etc/rc.d/7/userdaemon - User daemons started after normal boot # # start up mail delivery system /bin/su mmdf -c "/usr/mmdf/bin/deliver -b -clocal,uucp,list" echo "MMDF daemon deliver started" -----------------------------file ends here----------------------
david@twg.com (David S. Herron) (08/13/90)
In article <254@iscden.UUCP> jbev@iscden.UUCP (J.Bevier at Home on Hipeak) writes: >In article <1990Aug05.144539.5500@vlr@litwin.com> vlr@vlr@litwin.com (Vic Rice) writes: >>I recently discovered a problem with my mail system. I am using >>SCO Opendesktop (SYSV R3.2) which uses MMDF as its MTA. >>My problem is with mail arriving but not being delivered. I [Describes discovering mail he thought had disappeared sitting in a spooling directory] >The general problem here is that locks are used while mail is being >delivered. If a second piece of mail arrives to be delivered to a >mail box being updated, it will be put in /usr/spool/mmdf/lock/home/msg.* >to be delivered later. However, this can not take place unless deliver >is called to deliver the mail! Either run deliver manually or put the >following entry in the /etc/rc.d/7/udaemons file to have deliver run >in the background. That is exactly the cause for the problem. It is an extremely good ides to run a background deliver to catch those pieces of mail which don't get delivered immediately. Something slightly different you might want to do is turn off mod=imm on all of your channels and run a background deliver on 'em all. The command line would be: "deliver -cchan,chan,chan -b" .. What this will do is force all deliveries into the background daemon, with a useful side-effect. Because a deliver can only deliver one message at a time then you are limiting the load that MMDF will put on the system to 2-3 processes at a time. With other mail systems, and with MMDF if you configure with mod=imm, the system will generate as many delivery daemons as it can all at the same time. (Assuming that you have bursts of mail coming in). For instance ... one of the old problems with sendmail is that it will start up lots and lots and lots of sendmail's when there's lots of stuff in the queue. Systems have been known to crash because of that. But with mod=imm turned off on MMDF you're limited to as many mail-delivery "streams" as you have deliver's. -- <- 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!