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

[John Young]

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 
>>>>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
> storage.


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
the system).

-John Young