[ic] 'Unable to send mail' - ongoing issue
john_young at sonic.net
Wed Mar 2 19:57:40 EST 2005
Mike Heins wrote:
> 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
>>>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
If you don't mind losing session data upon reboot, and if you have
excess memory (ha!), then you could also consider making your session
directory a tmpfs type of filesystem. Might be a nice way to test
things, at least (if you could replicate the problem by overloading
More information about the interchange-users