RT 3.8.7 fails to send email sometimes - cannot allocate memory?

RT Users
1

Hi,

We have a strange situation where sometimes emails that should be sent are
not received (for example upon a reply via web or email).

I spent some time today trying to work out when this occurred, only to find
that it was working as expected for various permutations of reply / comment
etc to requestor / CC / Admin CC… until I went digging for a specific
ticket that I knew we’d witnessed this error with today.

This is what appeared in the logs when I (the owner) replied using the web
interface, which should have sent an email back to the requestor:

Aug 1 12:05:22 sirius RT: <
rt-3.8.7-28432-1312164322-125.78931-14-0@faredge.com.au> #78931/638647 -
Scrip 14 Notify Owner of Change
(/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:300)
Aug 1 12:05:22 sirius RT: <
rt-3.8.7-28432-1312164322-125.78931-14-0@faredge.com.au>: Could not send
mail with command /usr/sbin/sendmail -oi -t: couldn’t execute program:
Cannot allocate memory at
/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm line
432.#012#012Stack:#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:432]#012
[/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:307]#012
[/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:129]#012
[/usr/share/request-tracker3.8/lib/RT/ScripAction_Overlay.pm:238]#012
[/usr/share/request-tracker3.8/lib/RT/Scrip_Overlay.pm:464]#012
[/usr/share/request-tracker3.8/lib/RT/Scrips_Overlay.pm:196]#012
[/usr/share/request-tracker3.8/lib/RT/Transaction_Overlay.pm:188]#012
[/usr/share/request-tracker3.8/lib/RT/Record.pm:1457]#012
[/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:2831]#012 [(eval
3450):12]#012
[/usr/share/request-tracker3.8/lib/RT/ScripAction_Overlay.pm:238]#012
[/usr/share/request-tracker3.8/lib/RT/Scrip_Overlay.pm:464]#012
[/usr/share/request-tracker3.8/lib/RT/Scrips_Overlay.pm:196]#012
[/usr/share/request-tracker3.8/lib/RT/Transaction_Overlay.pm:188]#012
[/usr/share/request-tracker3.8/lib/RT/Record.pm:1457]#012
[/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:3323]#012
[/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:2996]#012
[/usr/share/request-tracker3.8/lib/RT/Record.pm:898]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:1340]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:1450]#012
[/usr/share/request-tracker3.8/html/Ticket/Display.html:156]#012
[/usr/share/request-tracker3.8/html/Ticket/Update.html:261]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:320]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:224]#012
[/usr/share/request-tracker3.8/html/autohandler:53]
(/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:448)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-42.79722-4-0@faredge.com.au> #79722/638648 - Scrip
4 On Correspond Notify AdminCcs
(/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:300)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-42.79722-4-0@faredge.com.au> No recipients found.
Not sending. (/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:342)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-331.79722-6-0@faredge.com.au> #79722/638648 -
Scrip 6 On Correspond Notify Other Recipients
(/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:300)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-331.79722-6-0@faredge.com.au> No recipients found.
Not sending. (/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:342)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-628.79722-5-0@faredge.com.au> #79722/638648 -
Scrip 5 On Correspond Notify Requestors and Ccs
(/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:300)
Aug 1 12:05:24 sirius RT: <
rt-3.8.7-28430-1312164324-628.79722-5-0@faredge.com.au>: Could not send mail
with command /usr/sbin/sendmail -oi -t: couldn’t execute program: Cannot
allocate memory at /usr/share/request-tracker3.8/lib/RT/Interface/Email.pm
line 432.#012#012Stack:#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:432]#012
[/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:307]#012
[/usr/share/request-tracker3.8/lib/RT/Action/SendEmail.pm:129]#012
[/usr/share/request-tracker3.8/lib/RT/ScripAction_Overlay.pm:238]#012
[/usr/share/request-tracker3.8/lib/RT/Scrip_Overlay.pm:464]#012
[/usr/share/request-tracker3.8/lib/RT/Scrips_Overlay.pm:196]#012
[/usr/share/request-tracker3.8/lib/RT/Transaction_Overlay.pm:188]#012
[/usr/share/request-tracker3.8/lib/RT/Record.pm:1457]#012
[/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:2175]#012
[/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:2087]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:1147]#012
[/usr/share/request-tracker3.8/html/Ticket/Display.html:146]#012
[/usr/share/request-tracker3.8/html/Ticket/Update.html:261]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:320]#012
[/usr/share/request-tracker3.8/lib/RT/Interface/Web.pm:224]#012
[/usr/share/request-tracker3.8/html/autohandler:53]
(/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm:448)

There are two places it’s trying to send an email here - the first is scrip
14 which notifies owner on change, and secondly scrip 5 notifying requestors
& Ccs on change.

Now, these two scrips look like:

Description: Notify Owner on change
Condition: On Owner Change
Action: Notify Owner
Template: Global template: Owner Change
Stage: TransactionCreate

Template:

This ticket has been assigned to you.

View the ticket at this location:
{$RT::WebURL}Ticket/Display.html?id

Description: On Correspond Notify Requestors and Ccs
Condition: On Correspond
Action: Notify Requestors and Ccs
Template: Global template: Correspondence
Stage: TransactionCreate

Template:
RT-Attach-Message: yes

{$Transaction->Content()}

With no custom conditions / actions / etc in either.

In qmail (not running on this particular box) I’ve seen what I suspect is a
similar thing when you load spam assassin, AV etc etc, which requires you to
increase the amount of memory available to the tcpserver via softlimit (exec
/usr/local/bin/softlimit -m 40000000 …) and so on. Is this what I’m seeing
here, and if so, how / what do I need to change? Or is it something else
entirely?

Thanks,

Chris

2

Aug 1 12:05:22 sirius RT:
<rt-3.8.7-28432-1312164322-125.78931-14-0@faredge.com.au
mailto:rt-3.8.7-28432-1312164322-125.78931-14-0@faredge.com.au>: Could
not send mail with command /usr/sbin/sendmail -oi -t: couldn’t execute
program: Cannot allocate memory at
/usr/share/request-tracker3.8/lib/RT/Interface/Email.pm line
432.#012#012Stack:#012
[snip]
In qmail (not running on this particular box) I’ve seen what I suspect
is a similar thing when you load spam assassin, AV etc etc, which
requires you to increase the amount of memory available to the tcpserver
via softlimit (exec /usr/local/bin/softlimit -m 40000000 …) and so on.
Is this what I’m seeing here, and if so, how / what do I need to change?
Or is it something else entirely?

You’re seeing effectively the same thing. Your machine is running out
of memory and there isn’t enough for the OS to run /usr/sbin/sendmail.
You should increase the memory available or decrease your memory use.

Thomas

3

But the box has heaps of memory free on it. I’ve been searching but can’t find anything that tells you how to up the per thread / process / etc memory limit. You can tune the number of workers and so forth in apache, but I don’t expect dropping that to help if there is still >1.5g free ram on the box?

4

But the box has heaps of memory free on it. I’ve been searching but
can’t find anything that tells you how to up the per thread / process
/ etc memory limit. You can tune the number of workers and so forth
in apache, but I don’t expect dropping that to help if there is still

1.5g free ram on the box?

There may be 1.5 gigs of free memory now, but there might not have been
when that log message was written. I’d start looking for cronjobs, etc.
that might have been running at the same time.

Thomas

5

Yes, I’ve grabbed the mrtgs for memory usage, and at about 9:30am yesterday
free ram plummeted on the box, and cleared itself up at about 12:30 or
shortly before I started looking at it. There are a few times a day when
free memory gets very low, but they don’t correlate with cron jobs…

I’ve tried tuning the following parameters in apache:

MaxClients          50

MaxRequestsPerChild   10000

dropping from 150, 0 respectively. The server doesn’t host any high volume /
usage sites and spends most of it’s day counting sheep so I’d rather the
(presumably) extra memory allocated per child and auto-cycling children in
case of memory leaks. I’ll watch this for a few days and see how memory
usage on the box compares then report back.

6

Ok, postscript: I haven’t seen the problem occur in the week since making
the change. Memory usage on the box hasn’t really changed at all, but the
error messages and the symptom have ceased and performance is still great so
currently looks like case closed, thankyou!

Regards,

ChrisOn 2 August 2011 10:43, Chris Herrmann chrisherrmann7@gmail.com wrote:

Yes, I’ve grabbed the mrtgs for memory usage, and at about 9:30am yesterday
free ram plummeted on the box, and cleared itself up at about 12:30 or
shortly before I started looking at it. There are a few times a day when
free memory gets very low, but they don’t correlate with cron jobs…

I’ve tried tuning the following parameters in apache:

MaxClients          50

MaxRequestsPerChild   10000

dropping from 150, 0 respectively. The server doesn’t host any high volume
/ usage sites and spends most of it’s day counting sheep so I’d rather the
(presumably) extra memory allocated per child and auto-cycling children in
case of memory leaks. I’ll watch this for a few days and see how memory
usage on the box compares then report back.