Down System

Need help tracking down what is causing these messages.

Please help

[Thu Mar 12 18:19:47 2015] [error] [client 192.168.250.231] Premature end of script headers: rt-server.fcgi
[Thu Mar 12 18:19:54 2015] [warn] [client 192.168.250.231] mod_fcgid: read data timeout in 40 seconds
[Thu Mar 12 18:19:54 2015] [error] [client 192.168.250.231] Premature end of script headers: rt-server.fcgi

Thanks Bryon
Bryon Baker
Network Operations Manager
Copesan - Specialists in Pest Solutions
800-267-3726 • 262-783-6261 ext. 2296
bbaker@copesan.commailto:cstephan@copesan.com
www.copesan.comhttp://www.copesan.com/

Need help tracking down what is causing these messages.

What happens if you run the script from the command line? Maybe
there’s a missing library due to an automatic upgrade?

Luca

I do not have the system set to allow automatic upgrades.

It appears that it have been cause by some testing I was doing, delete a couple of test tickets that had a very large amount of transactions. The system seems to be running fine after that task was complete.

Which raises another concern it the problem just lurking around waiting to strike again.

Thanks
Bryon Baker
Network Operations Manager
Copesan - Specialists in Pest Solutions
800-267-3726 • 262-783-6261 ext. 2296
bbaker@copesan.com

“Servicing North America with Local Care”-----Original Message-----
From: fluca1978@gmail.com [mailto:fluca1978@gmail.com] On Behalf Of Luca Ferrari
Sent: Friday, March 13, 2015 2:42 AM
To: Bryon Baker
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Down System

On Fri, Mar 13, 2015 at 12:23 AM, Bryon Baker bbaker@copesan.com wrote:

Need help tracking down what is causing these messages.

What happens if you run the script from the command line? Maybe there’s a missing library due to an automatic upgrade?

Luca

I do not have the system set to allow automatic upgrades.

It appears that it have been cause by some testing I was doing, delete a couple of test tickets that had a very large amount of transactions. The system seems to be running fine after that task was complete.

Which raises another concern it the problem just lurking around waiting to strike again.

Hi Bryon,

You need to increase your fcgi timeout value to allow for an
update that takes a long period of time. 40s is way too small.
You need to be able to accomodate the longest query that you
typically run from RT. We have some very long reporting dashboards
and have a 12h timeout to allow them to complete. The mod_perl
configuration we used to use had no timeout at all, for example.
Now by and large most responses take a very short period of time
but you need to allow for the occasional long ones, as you noticed.

Regards,
Ken

Thanks Ken
I can increase that value but is there any why to see what script or query is taking the longest?

Thanks
Bryon Baker
Network Operations Manager
Copesan - Specialists in Pest Solutions
800-267-3726 . 262-783-6261 ext. 2296
bbaker@copesan.com

“Servicing North America with Local Care”-----Original Message-----
From: ktm@rice.edu [mailto:ktm@rice.edu]
Sent: Friday, March 13, 2015 9:00 AM
To: Bryon Baker
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Down System

On Fri, Mar 13, 2015 at 11:55:41AM +0000, Bryon Baker wrote:

I do not have the system set to allow automatic upgrades.

It appears that it have been cause by some testing I was doing, delete a couple of test tickets that had a very large amount of transactions. The system seems to be running fine after that task was complete.

Which raises another concern it the problem just lurking around waiting to strike again.

Hi Bryon,

You need to increase your fcgi timeout value to allow for an update that takes a long period of time. 40s is way too small.
You need to be able to accomodate the longest query that you typically run from RT. We have some very long reporting dashboards and have a 12h timeout to allow them to complete. The mod_perl configuration we used to use had no timeout at all, for example.
Now by and large most responses take a very short period of time but you need to allow for the occasional long ones, as you noticed.

Regards,
Ken