[ic] 'Unable to send mail' - ongoing issue
John Young
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
>>>>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
More information about the interchange-users
mailing list