[rt-users] RT stopped sending mail / No recipients found. Not sending.

Alexander Rudolf Gruber alexander.gruber at abaton.at
Tue Jan 8 11:18:25 EST 2008


*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




More information about the rt-users mailing list