[ic] 'Unable to send mail' - ongoing issue
db at kavod.com
Wed Mar 2 16:44:19 EST 2005
* Mike Heins <mike at perusion.com> [2005-03-02 12:41]:
> 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
That's a good idea, maybe I'll do that. (You've actually suggested that to me
in the past, and I've even done it on a different system, but I've forgotten all
I didn't mention it before, but the system is using RAID-5. RAID-5 can
never be as fast as a non-RAID as writes (except for the very short time
that it hits the write cache), but a RAID-10 system should theoretically be
twice as fast on writes.
Daniel Browning <db at kavod.com> - Kavod Technologies. Random Fortune:
"May your future be limited only by your dreams."
-- Christa McAuliffe
More information about the interchange-users