Hi folks<br><br>I have recently experienced this same problem too, and would like to comment on what I did as a workaround. To recap on the problem:<br><br>Outgoing email is not sent by RT, and " Outgoing email recorded
    " does not appear on the ticket. Restarting Apache resolves this temporarily. It is definitely related to sending large messages. To reproduce, I simply send an email via RT with a large attachment (4MB) and RT will stop sending mail until the next restart of Apache. The Apache error log shows it is unable to allocate sufficient memory to launch sendmail:<br>
<br>"Couldn't run /usr/sbin/sendmail: Cannot allocate memory at /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm line 320."<br><br>In my case I am using exim4, so sendmail is just a symlink to that.<br>
<br>Alexander found a workaround for himself below, and I would like to add to this conversation what I did to fix it.<br><br>I run Apache/2.2.8 (Ubuntu 8.04) mod_perl/2.0.3 Perl/v5.8.8 and Exim 4.69. I seem to have found a workaround for this by replacing the Apache "worker" MPM (mutli-processing module) with the older "prefork" MPM. On Ubuntu 8.04 this can be done by issuing "apt-get install apache2-mpm-prefork". The difference is that worker uses threads whereas prefork only uses processes for concurrency. This is obviously not ideal, as you want RT to work with any of the Apache MPMs.<br>
<br>Then I realised that while I am using Exim4, RT is configured to use "sendmailpipe", so a more correct solution (than reconfiguring apache) might be to change this setting to just "sendmail", under the assumtion that the "sendmailpipe" version is not compatible with other MTAs such as Exim. Interestingly, this change does fix the issue. But unfortunately Exim sets the envelope sender of the email to the local user (www-data@f.q.d.n) instead of the desired email address (which is in thre From: header of the mail). In some mail clients this results in sender listed as:<br>
<br>www-data [www-data@f.q.d.n]; on behalf of; Richard Brady [<a href="mailto:support@example.com">support@example.com</a>]. <br><br>To get around this, RT needs to pass an envelope sender in the arguments to senfdmail (exim4), which is currently not done in SendEmail.pm.<br>
<br>So I have gone with installing apache2-mpm-prefork as my workaround.<br><br>Regards,<br>Richard<br><br><br><div class="gmail_quote">On Tue, Jan 8, 2008 at 4:18 PM, Alexander Rudolf Gruber wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
*My problem with the RT-System has been resolved!*<br>
<br>
I've added an additional debug-level and got this:<br>
-- snip --<br>
Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> #450/6880 - Scrip 7  (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:238)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Debug: After Recipients. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:254)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Debug: After Header. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:261)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Debug: After SendmailArguments. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:271)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Debug: 'sendmailpipe' (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:274)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Debug: Couldn't run /usr/sbin/sendmail: Cannot allocate memory (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:281)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> Mail: GLOB(0xd9507a8) (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:282)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>> SendmailArguments: -oi -t (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:283)<br>



Jan  3 12:30:08 rt RT: <<a href="mailto:rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at" target="_blank">rt-3.6.1-24121-1199359807-997.450-7-0@rt.abaton.at</a>>Debug: Could not send mail. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:300)<br>



-- snap --<br>
<br>
Then I knew it had something to do with a memory problem - although "free" showed me:<br>
<br>
rt:/var/log# free -m<br>
            total       used       free     shared    buffers     cached<br>
Mem:          2006       1970         35          0        135       1019<br>
-/+ buffers/cache:        816       1190<br>
Swap:         4094          0       4094<br>
<br>
This was certainly not the problem, so I went deeper.<br>
Further investigation got me:<br>
<br>
cat /vz/root/104/proc/user_beancounters<br>
Version: 2.5<br>
      uid  resource                     held              maxheld              barrier                limit              failcnt<br>
     104:  kmemsize                  4806443              6109370             32307712             32307712                    0<br>
           lockedpages                     0                    0                  128                  128                    0<br>
           privvmpages                230693               350667              2880450              3200500                  106<br>
           shmpages                       57                 1993                19121                19121                    0<br>
           dummy                           0                    0                    0                    0                    0<br>
           numproc                        80                   93                  650                  650                    0<br>
           physpages                   91609               142076                    0           2147483647                    0<br>
           vmguarpages                     0                    0                78565           2147483647                    0<br>
           oomguarpages                91609               142076                24576           2147483647                    0<br>
           numtcpsock                      6                   22                  540                  540                    0<br>
           numflock                        4                    8                  252                  280                    0<br>
           numpty                          0                    2                   16                   16                    0<br>
           numsiginfo                      2                    6                  256                  256                    0<br>
           tcpsndbuf                  104832               644416              2949120              4915200                    0<br>
           tcprcvbuf                   98304               341872              4128768              6881280                    0<br>
           othersockbuf                13856              1212608              1365012              3500032                    0<br>
           dgramrcvbuf                     0                 8464               368640               368640                    0<br>
           numothersock                   16                   29                  561                  561                    0<br>
           dcachesize                      0                    0              5662310              6291456                    0<br>
           numfile                      1365                 1790                12288                12288                    0<br>
           dummy                           0                    0                    0                    0                    0<br>
           dummy                           0                    0                    0                    0                    0<br>
           dummy                           0                    0                    0                    0                    0<br>
           numiptent                      10                   10                  128                  128                    0<br>
<br>
So /privvmpages /was the problem (failcount 106 = 106 times RT could not send mail due to page shortage) - I raised the respective value by factor 10 and the system was able to send mails since then. Testing the system on its own (which I did before) showed that I could definitely send mails from the system, the system was not out of disk-space and I had plenty ram/swap avaliable.<br>



<br>
The rather odd thing was that there where no fail-messages from RT at all (I mean before I added my own debug-level) or I would have solved the mystery much earlier.<br>
<br>
Thanks for all the hints and help everyone gave me!<br>
<br>
best wishes,<br>
Alexander<br>
<br>
<a href="mailto:o.nash@cs.ucc.ie" target="_blank">o.nash@cs.ucc.ie</a> schrieb:<div><div></div><div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Re sending emails from Rt<br>
if your mailserver is postfix, you might need to add the hostname of the server running RT to the 'relayhosts' variable in postfix.<br>
or the equivalent in <a href="http://sendmail.cf" target="_blank">sendmail.cf</a><br>
<br>
regards<br>
Oliver<br>
<br>
On Thu, 3 Jan 2008, Alexander Rudolf Gruber wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for the many replies everyone and a happy new year 2008!<br>
<br>
I've been away over the holidays and now I'm trying to resolve that<br>
matter for good :-)<br>
My replies to the respective postings are below.<br>
<br>
Best wishes and thanks for your help!<br>
Alexander<br>
<br>
PS: I messed up my first posting of that message sending it to <a href="mailto:rt-users-bounces@lists.bestpractical.com" target="_blank">rt-users-bounces@lists.bestpractical.com</a> instead of <a href="mailto:rt-users@lists.bestpractical.com" target="_blank">rt-users@lists.bestpractical.com</a> (copied the wrong address).<br>



<br>
Benjamin Weser schrieb:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We had the problem of RT not sending mails to anybody too. But I don't think that there were messages about that in rt.log because the fault was that somebody changed the IP of the mailserver. So all mails sent by RT stayed in the spool of postfix unless I corrected the postfix configuration with the new IP address of the mailserver. Unfortunately I can't check the logfile anymore because it doesn't contain information from this time anymore. But maybe that's another part of the system where you can have a look at. Good luck!<br>



<br>
Ben<br>
</blockquote>
Ben,<br>
<br>
it seems I can't pinpoint the problem at all. Just today the system sent<br>
mail - initiated by the scrip that notifies the owner of a ticket of any<br>
changes (meaning the RT-System CAN send mail). Still it fails to send<br>
mail regarding correspondence or any CC types. The frustrating thing is<br>
that the system tells me that mail will be sent to the listed recipients<br>
- so it looks like the scrips are working as they should - it just<br>
doesn't do it for whatever reason.<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
Kenneth Crocker schrieb:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Stephen,<br>
<br>
<br>
    AAAAAHHHHHHH! Kool. I just learned something. Then I really can't see why RT can't find a recipient unless there is some disconnection between what RT is looking for and where it looks for it. Alexander said there were no changes to RT. The scrips are triggering, RT is looking, nothing is found, no email goes out, but probably would have if RT had found a recipient. I'm sure he checked the "organization" set to the DNS name of the host" problem from before. I'm at a loss, but that's no big surprise since I am just now getting to learn about the "internals" of RT. Hope someone has an idea that works for him.<br>



<br>
<br>
Kenn<br>
LBNL<br>
<br>
On 12/20/2007 10:44 AM, Stephen Turner wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At Thursday 12/20/2007 01:26 PM, Kenneth Crocker wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Alexander,<br>
<br>
        I agree. If RT could not access the DB, then a lot of things would not be working. However, my point was really that based on the content of the error message, RT thinks that it hasn't FOUND the recipient. There could, and probably are, many possible reasons for that. Perhaps after accessing the DB, the data gets lost in transition or put into an area that got misnamed or is not accessible for some reason. I am not a "Systems" guy when it comes to playing with those technologies (UNIX, ORACLE, MySQL, etc.), but I have been in the business for a long time and my debugging skills tell me that RT is having trouble with either capturing the data or finding/recognizing it after it has been captured/found/stored. Somewhere in that process, the data is either getting lost or it becomes unrecognizable, ergo the error message you're getting. Sorry I can't be of more help. I am REALLY interested in what you DO find when you get the problem resolved. Best of luck.<br>



<br>
Kenn<br>
LBNL<br>
</blockquote>
<br>
</blockquote></blockquote></blockquote>
Kenn,<br>
<br>
well ... I don't have much of a clue what to do next at all. I can try<br>
and upgrade to the newest version and see if that makes things better in<br>
any way. If that fails I could try tracing the error maybe I'll be able<br>
to find whats wrong. If that doesn't get me anywhere either I guess I'll<br>
clone the VE and raise a new instance of RT and switch that with the<br>
broken one as soon as everything is configured as it should be.<br>
<br>
I'll let you know in any case what I did as soon as that problem is<br>
resolved.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The "No recipients found" message just means that the scrip decided that nobody should receive mail for this transaction - it doesn't mean that data is missing or corrupt. For example - if you have a scrip with action 'Notify AdminCcs' and there are no AdminCcs for the ticket or queue, you'll see this message in the log.<br>



<br>
Steve<br>
<br>
<br>
</blockquote></blockquote></blockquote>
Steve,<br>
<br>
as mentioned above, the system tells me that mail will be sent to<br>
following addresses and it offers me an option to supress the sending<br>
(lower part of the correspondence form). It just does not do anything<br>
apart from recording a message to the RT-Log, like a comment with no<br>
email sent - and I get the message in the systemlog that there are no<br>
recipients found.<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:<br>
<br>
If you sign up for a new RT support contract before December 31, we'll take<br>
up to 20 percent off the price. This sale won't last long, so get in touch today.    Email us at <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a> or call us at +1 617 812 0745.<br>



<br>
<br>
Community help: <a href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br>
Commercial support: <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at <a href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br>
</blockquote>
<br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:<br>
<br>
If you sign up for a new RT support contract before December 31, we'll take<br>
up to 20 percent off the price. This sale won't last long, so get in touch today.    Email us at <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a> or call us at +1 617 812 0745.<br>



<br>
<br>
Community help: <a href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br>
Commercial support: <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at <a href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
______________________________________<br>
<br>
     Alexander Rudolf Gruber<br>
  abaton EDV-Dienstleistungs GmbH<br>
______________________________________<br>
<br>
Wielandgasse 14-16/IV/B11  A-8010 Graz<br>
Mariahilfer Straße 1d/13   A-1060 Wien<br>
LG f. ZRS Graz, FN202006v, ATU52569000<br>
Tel: +43 (0) 316/817 896-0  Fax: DW 70<br>
<a href="http://www.abaton.at" target="_blank">www.abaton.at</a> <a href="mailto:alexander.gruber@abaton.at" target="_blank">alexander.gruber@abaton.at</a><br>
<br>
<br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:<br>
<br>
If you sign up for a new RT support contract before December 31, we'll take<br>
up to 20 percent off the price. This sale won't last long, so get in touch today.    Email us at <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a> or call us at +1 617 812 0745.<br>



<br>
<br>
Community help: <a href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br>
Commercial support: <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at <a href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br>
<br>
</blockquote>
<br>
-- <br>
Oliver Nash<br>
</blockquote>
<br>
<br>
-- <br>
______________________________________<br>
<br>
      Alexander Rudolf Gruber<br>
   abaton EDV-Dienstleistungs GmbH<br>
______________________________________<br>
<br>
Wielandgasse 14-16/IV/B11  A-8010 Graz<br>
Mariahilfer Straße 1d/13   A-1060 Wien<br>
LG f. ZRS Graz, FN202006v, ATU52569000<br>
Tel: +43 (0) 316/817 896-0  Fax: DW 70<br>
<a href="http://www.abaton.at" target="_blank">www.abaton.at</a> <a href="mailto:alexander.gruber@abaton.at" target="_blank">alexander.gruber@abaton.at</a><br>
<br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:<br>
<br>
If you sign up for a new RT support contract before December 31, we'll take<br>
up to 20 percent off the price. This sale won't last long, so get in touch today.    Email us at <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a> or call us at +1 617 812 0745.<br>



<br>
<br>
Community help: <a href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br>
Commercial support: <a href="mailto:sales@bestpractical.com" target="_blank">sales@bestpractical.com</a><br>
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at <a href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br>
</div></div></blockquote></div><br>