A problem appeared today where the browser hangs when the status of a
ticket is changed.
There do not seem to be any associated errors in the log file, and the
page waits for about 30 seconds and then goes to a blank page.
I have the level set to debug;
[Tue Feb 19 18:44:54 2008] [debug]: About to think about scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:167)
[Tue Feb 19 18:44:54 2008] [debug]: About to prepare scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:171)
[Tue Feb 19 18:44:54 2008] [debug]: Found 2 scrips
(/opt/rt3/lib/RT/Scrips_Overlay.pm:365)
[Tue Feb 19 18:44:54 2008] [debug]: About to commit scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:180)
[Tue Feb 19 18:44:55 2008] [info]: rt-3.6.5-6928-1203446694-488.545-10-0@example.com#545/6402 - Scrip 10
(/opt/rt3/lib/RT/Action/SendEmail.pm:252)
[Tue Feb 19 18:44:55 2008] [info]: rt-3.6.5-6928-1203446694-488.545-10-0@example.com sent To:
root@dcmon01.osti.local (/opt/rt3/lib/RT/Action/SendEmail.pm:283)
[Tue Feb 19 18:44:56 2008] [debug]: About to think about scrips for
transaction #6403 (/opt/rt3/lib/RT/Transaction_Overlay.pm:167)
Would you mind listing for me any scrips you have relating to a status
change and emails as a result of said change? What kind of action
precipitated the initial scrip being triggered? Could be that an email
notification scrip is looking for a template that you modified or
misnamed (capitol letters?, etc.) and can’t find it. Anyway, that list
and their contents will help the debugging process.
Kenn
LBNLOn 2/19/2008 10:49 AM, Tom Hodder wrote:
Hi,
A problem appeared today where the browser hangs when the status of a
ticket is changed.
There do not seem to be any associated errors in the log file, and the
page waits for about 30 seconds and then goes to a blank page.
I have the level set to debug;
[Tue Feb 19 18:44:54 2008] [debug]: About to think about scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:167)
[Tue Feb 19 18:44:54 2008] [debug]: About to prepare scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:171)
[Tue Feb 19 18:44:54 2008] [debug]: Found 2 scrips
(/opt/rt3/lib/RT/Scrips_Overlay.pm:365)
[Tue Feb 19 18:44:54 2008] [debug]: About to commit scrips for
transaction #6402 (/opt/rt3/lib/RT/Transaction_Overlay.pm:180)
[Tue Feb 19 18:44:55 2008] [info]: rt-3.6.5-6928-1203446694-488.545-10-0@example.com#545/6402 - Scrip 10
(/opt/rt3/lib/RT/Action/SendEmail.pm:252)
[Tue Feb 19 18:44:55 2008] [info]: rt-3.6.5-6928-1203446694-488.545-10-0@example.com sent To:
root@dcmon01.osti.local (/opt/rt3/lib/RT/Action/SendEmail.pm:283)
[Tue Feb 19 18:44:56 2008] [debug]: About to think about scrips for
transaction #6403 (/opt/rt3/lib/RT/Transaction_Overlay.pm:167)
Would you mind listing for me any scrips you have relating to a status
change and emails as a result of said change? What kind of action
precipitated the initial scrip being triggered? Could be that an email
notification scrip is looking for a template that you modified or
misnamed (capitol letters?, etc.) and can’t find it. Anyway, that list
and their contents will help the debugging process.
All the scrips that run against any of the queues are in the global
list;
Scrips which apply to all queues
* (Scrip #1)
On Correspond Open Tickets with template Blank
* (Scrip #2)
On Owner Change Notify Owner with template Transaction
* (Scrip #3)
On Create Autoreply To Requestors with template Autoreply
* (Scrip #4)
On Create Notify AdminCcs with template Transaction
* (Scrip #5)
On Correspond Notify AdminCcs with template Admin Correspondence
* (Scrip #6)
On Correspond Notify Requestors with template Correspondence
* (Scrip #7)
On Correspond Notify Other Recipients with template
Correspondence
* (Scrip #8)
On Comment Notify AdminCcs as Comment with template Admin
Comment
* (Scrip #9)
On Comment Notify Other Recipients as Comment with template
Correspondence
* (Scrip #10)
On Resolve Notify Requestors with template Resolved
* (Scrip #18)
On Create Notify Ccs with template Transaction
* (Scrip #19)
On Correspond Notify Owner with template Correspondence
* (Scrip #20)
On Comment Notify Owner as Comment with template Correspondence
The templates are the same;
Blank
A blank template Autoreply
Default Autoresponse template Transaction
Default transaction template Admin Correspondence
Default admin correspondence template Correspondence
Default correspondence template Admin Comment
Default admin comment template Status Change
Ticket status changed Resolved
Ticket Resolved New Ticket Notify
Notify all the users who are TakeTicket group that a ticket is available
Is there any way to get rt to provide any more debugging information?
(apologies for the html email, but I wanted to paste an html table)On Tue, 2008-02-19 at 10:59 -0800, Kenneth Crocker wrote:
Tom,
Would you mind listing for me any scrips you have relating to a status
change and emails as a result of said change? What kind of action
precipitated the initial scrip being triggered? Could be that an email
notification scrip is looking for a template that you modified or
misnamed (capitol letters?, etc.) and can’t find it. Anyway, that list
and their contents will help the debugging process.
It seems to hang for example when changing the ticket status from
“resolves” to “open”, the last line in the log is;
[Wed Feb 20 17:06:11 2008] [debug]: About to commit scrips for
transaction #6464 (/opt/rt3/lib/RT/Transaction_Overlay.pm:180)
I checked out transaction id #6464 and its just this;
SELECT * FROM Transactions T where id = ‘6464’ LIMIT 0,10000
id
ObjectType
ObjectId
TimeTaken
Type
Field
OldValue
NewValue
ReferenceType
OldReference
NewReference
Data
Creator
Created
6464
RT::Ticket
545
0
Status
Status
resolved
open
22
2008-02-20 17:06:10
there are no logs, in the apache error_log or fastcgi log
A problem appeared today where the browser hangs when the status of a
ticket is changed.
There do not seem to be any associated errors in the log file, and the
page waits for about 30 seconds and then goes to a blank page.
In the end this was related to the request size, and was actually a
network error where the firewall was truncating the packets. The exact
details are which are currently being post-mortemed by our network team.
Many Thanks for the pointers that were given, and its good to know that
RT was functioning perfectly all the time.