[rt-users] RT stopped sending mail / No recipients found. Not sending.
Richard Brady
rnbrady at gmail.com
Mon Nov 24 12:36:02 EST 2008
Hi folks
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:
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:
"Couldn't run /usr/sbin/sendmail: Cannot allocate memory at
/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm line 320."
In my case I am using exim4, so sendmail is just a symlink to that.
Alexander found a workaround for himself below, and I would like to add to
this conversation what I did to fix it.
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.
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 at 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:
www-data [www-data at f.q.d.n]; on behalf of; Richard Brady [
support at example.com].
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.
So I have gone with installing apache2-mpm-prefork as my workaround.
Regards,
Richard
On Tue, Jan 8, 2008 at 4:18 PM, Alexander Rudolf Gruber wrote:
> *My problem with the RT-System has been resolved!*
>
> I've added an additional debug-level and got this:
> -- snip --
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> #450/6880 - Scrip 7
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:238)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Debug: After Recipients.
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:254)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Debug: After Header.
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:261)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Debug: After SendmailArguments.
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:271)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Debug: 'sendmailpipe'
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:274)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Debug: Couldn't run /usr/sbin/sendmail: Cannot allocate memory
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:281)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> Mail: GLOB(0xd9507a8)
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:282)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>
> SendmailArguments: -oi -t
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:283)
> Jan 3 12:30:08 rt RT: <rt-3.6.1-24121-1199359807-997.450-7-0 at rt.abaton.at>Debug:
> Could not send mail.
> (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:300)
> -- snap --
>
> Then I knew it had something to do with a memory problem - although "free"
> showed me:
>
> rt:/var/log# free -m
> total used free shared buffers cached
> Mem: 2006 1970 35 0 135 1019
> -/+ buffers/cache: 816 1190
> Swap: 4094 0 4094
>
> This was certainly not the problem, so I went deeper.
> Further investigation got me:
>
> cat /vz/root/104/proc/user_beancounters
> Version: 2.5
> uid resource held maxheld
> barrier limit failcnt
> 104: kmemsize 4806443 6109370
> 32307712 32307712 0
> lockedpages 0 0
> 128 128 0
> privvmpages 230693 350667
> 2880450 3200500 106
> shmpages 57 1993
> 19121 19121 0
> dummy 0 0
> 0 0 0
> numproc 80 93
> 650 650 0
> physpages 91609 142076
> 0 2147483647 0
> vmguarpages 0 0
> 78565 2147483647 0
> oomguarpages 91609 142076
> 24576 2147483647 0
> numtcpsock 6 22
> 540 540 0
> numflock 4 8
> 252 280 0
> numpty 0 2
> 16 16 0
> numsiginfo 2 6
> 256 256 0
> tcpsndbuf 104832 644416
> 2949120 4915200 0
> tcprcvbuf 98304 341872
> 4128768 6881280 0
> othersockbuf 13856 1212608
> 1365012 3500032 0
> dgramrcvbuf 0 8464
> 368640 368640 0
> numothersock 16 29
> 561 561 0
> dcachesize 0 0
> 5662310 6291456 0
> numfile 1365 1790
> 12288 12288 0
> dummy 0 0
> 0 0 0
> dummy 0 0
> 0 0 0
> dummy 0 0
> 0 0 0
> numiptent 10 10
> 128 128 0
>
> 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.
>
> 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.
>
> Thanks for all the hints and help everyone gave me!
>
> best wishes,
> Alexander
>
> o.nash at cs.ucc.ie schrieb:
>
> Re sending emails from Rt
>> if your mailserver is postfix, you might need to add the hostname of the
>> server running RT to the 'relayhosts' variable in postfix.
>> or the equivalent in sendmail.cf
>>
>> regards
>> Oliver
>>
>> On Thu, 3 Jan 2008, Alexander Rudolf Gruber wrote:
>>
>> Thanks for the many replies everyone and a happy new year 2008!
>>>
>>> I've been away over the holidays and now I'm trying to resolve that
>>> matter for good :-)
>>> My replies to the respective postings are below.
>>>
>>> Best wishes and thanks for your help!
>>> Alexander
>>>
>>> PS: I messed up my first posting of that message sending it to
>>> rt-users-bounces at lists.bestpractical.com instead of
>>> rt-users at lists.bestpractical.com (copied the wrong address).
>>>
>>> Benjamin Weser schrieb:
>>>
>>>> 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!
>>>>
>>>> Ben
>>>>
>>> Ben,
>>>
>>> it seems I can't pinpoint the problem at all. Just today the system sent
>>> mail - initiated by the scrip that notifies the owner of a ticket of any
>>> changes (meaning the RT-System CAN send mail). Still it fails to send
>>> mail regarding correspondence or any CC types. The frustrating thing is
>>> that the system tells me that mail will be sent to the listed recipients
>>> - so it looks like the scrips are working as they should - it just
>>> doesn't do it for whatever reason.
>>>
>>>>
>>>>
>>>>
>>>> Kenneth Crocker schrieb:
>>>>
>>>>> Stephen,
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> Kenn
>>>>> LBNL
>>>>>
>>>>> On 12/20/2007 10:44 AM, Stephen Turner wrote:
>>>>>
>>>>>> At Thursday 12/20/2007 01:26 PM, Kenneth Crocker wrote:
>>>>>>
>>>>>>> Alexander,
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Kenn
>>>>>>> LBNL
>>>>>>>
>>>>>>
>>>>>> Kenn,
>>>
>>> well ... I don't have much of a clue what to do next at all. I can try
>>> and upgrade to the newest version and see if that makes things better in
>>> any way. If that fails I could try tracing the error maybe I'll be able
>>> to find whats wrong. If that doesn't get me anywhere either I guess I'll
>>> clone the VE and raise a new instance of RT and switch that with the
>>> broken one as soon as everything is configured as it should be.
>>>
>>> I'll let you know in any case what I did as soon as that problem is
>>> resolved.
>>>
>>>
>>> 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.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>> Steve,
>>>
>>> as mentioned above, the system tells me that mail will be sent to
>>> following addresses and it offers me an option to supress the sending
>>> (lower part of the correspondence form). It just does not do anything
>>> apart from recording a message to the RT-Log, like a comment with no
>>> email sent - and I get the message in the systemlog that there are no
>>> recipients found.
>>>
>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>>>
>>>>> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
>>>>>
>>>>> If you sign up for a new RT support contract before December 31, we'll
>>>>> take
>>>>> up to 20 percent off the price. This sale won't last long, so get in
>>>>> touch today. Email us at sales at bestpractical.com or call us at +1
>>>>> 617 812 0745.
>>>>>
>>>>>
>>>>> Community help: http://wiki.bestpractical.com
>>>>> Commercial support: sales at bestpractical.com
>>>>>
>>>>>
>>>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>>>>> Buy a copy at http://rtbook.bestpractical.com
>>>>>
>>>>
>>>> _______________________________________________
>>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>>
>>>> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
>>>>
>>>> If you sign up for a new RT support contract before December 31, we'll
>>>> take
>>>> up to 20 percent off the price. This sale won't last long, so get in
>>>> touch today. Email us at sales at bestpractical.com or call us at +1
>>>> 617 812 0745.
>>>>
>>>>
>>>> Community help: http://wiki.bestpractical.com
>>>> Commercial support: sales at bestpractical.com
>>>>
>>>>
>>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy
>>>> a copy at http://rtbook.bestpractical.com
>>>>
>>>>
>>>>
>>>
>>> --
>>> ______________________________________
>>>
>>> Alexander Rudolf Gruber
>>> abaton EDV-Dienstleistungs GmbH
>>> ______________________________________
>>>
>>> Wielandgasse 14-16/IV/B11 A-8010 Graz
>>> Mariahilfer Straße 1d/13 A-1060 Wien
>>> LG f. ZRS Graz, FN202006v, ATU52569000
>>> Tel: +43 (0) 316/817 896-0 Fax: DW 70
>>> www.abaton.at alexander.gruber at abaton.at
>>>
>>>
>>> _______________________________________________
>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
>>>
>>> If you sign up for a new RT support contract before December 31, we'll
>>> take
>>> up to 20 percent off the price. This sale won't last long, so get in
>>> touch today. Email us at sales at bestpractical.com or call us at +1 617
>>> 812 0745.
>>>
>>>
>>> Community help: http://wiki.bestpractical.com
>>> Commercial support: sales at bestpractical.com
>>>
>>>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy
>>> a copy at http://rtbook.bestpractical.com
>>>
>>>
>> --
>> Oliver Nash
>>
>
>
> --
> ______________________________________
>
> Alexander Rudolf Gruber
> abaton EDV-Dienstleistungs GmbH
> ______________________________________
>
> Wielandgasse 14-16/IV/B11 A-8010 Graz
> Mariahilfer Straße 1d/13 A-1060 Wien
> LG f. ZRS Graz, FN202006v, ATU52569000
> Tel: +43 (0) 316/817 896-0 Fax: DW 70
> www.abaton.at alexander.gruber at abaton.at
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
>
> If you sign up for a new RT support contract before December 31, we'll take
> up to 20 percent off the price. This sale won't last long, so get in touch
> today. Email us at sales at bestpractical.com or call us at +1 617 812
> 0745.
>
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a
> copy at http://rtbook.bestpractical.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20081124/30de537b/attachment.htm>
More information about the rt-users
mailing list