[ic] 'Unable to send mail' - ongoing issue

Mike Heins mike at perusion.com
Wed Mar 2 15:30:40 EST 2005

Quoting Daniel Browning (db at kavod.com):
> * Jon Jensen <jon at endpoint.com> [2005-01-04 17:22]:
> > On Tue, 4 Jan 2005, Ed LaFrance wrote:
> > 
> > >I've just started working on a new client's system, and I see they are 
> > >plagued with a problem that I have observed on a myriad of other 
> > >installations. Namely, various emails sent by Interchange occasionally do 
> > >not go out. The failed sends can be found in the catalog error log, 
> > >preceded by the string 'Unable to send mail using (sendmail or similar)'. 
> > >I have seen order reports, customer receipts, contact messages and more 
> > >email types fail in this manner, sent by both email UserTags and 
> > >Interchange's internal mailing routines. I've seen this on Red Hat, 
> > >Debian, FreeBSD, and Solaris systems - maybe more, but those are the ones 
> > >that come to mind. In all cases, the systems have plenty of available RAM, 
> > >disk space and CPU resources.
> > >
> > >In one case I hacked the source a bit to capture some system error info to 
> > >the catalog error.log, and the system said the cause was a 'broken pipe'. 
> > >This was only on one system, so I don't know if that holds true for all 
> > >cases.
> > 
> > Ed,
> > 
> > That sounds like the classic Perl signals problem to me. Have you tried 
> > the remedies previously discussed on the list, of MaxServers 0 in 
> > interchange.cfg and PERL_SIGNALS=unsafe in the environment?
> [Continuing a very old thread]
> I periodically get this problem on one catalog.  I have been running PreFork
> with PERL_SIGNALS=unsafe the whole time.  It occurs during heavy system load.
> This is on a Red Hat Enterprise 3 Dual 2 ghz with 2GB ram and a fast RAID. Perl
> 5.8.3, 5.8.4, and 5.8.5 all seem to experience the issue.  It has occurred about
> 1-2 times per month for the last six months.

If your system is RAID for everything, even for sessions, you are
probably running into disk latency problems. Don't believe the hogwash
the RAID controller makers will tell you, that their controllers are
faster for write. I have tested it many times, and with frequent writes
I am always able to demonstrate that eventually you will get the RAID
controller to have a significant slippage causing slowdown.

Your best bet is to have a non-RAID disk and use that for your session

Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

I am convinced that life is 10% what happens to me and 90%
how I react to it. And so it is for you... we are in charge
of our attitudes. -- Charles Swindoll

More information about the interchange-users mailing list