*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:
<[EMAIL PROTECTED]> #450/6880 - Scrip
7 (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:238)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> Debug: After
Recipients. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:254)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> Debug: After
Header. (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:261)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> Debug: After
SendmailArguments.
(/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:271)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> Debug:
'sendmailpipe'
(/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:274)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> 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:
<[EMAIL PROTECTED]> Mail:
GLOB(0xd9507a8)
(/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:282)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]> SendmailArguments:
-oi -t (/usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm:283)
Jan 3 12:30:08 rt RT:
<[EMAIL PROTECTED]>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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] instead of
[email protected] (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 [EMAIL PROTECTED] or call us
at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] or call us at +1
617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED] or call us at +1
617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED] or call us at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
