Ygtjki

I am trying to access my iRedMail backend at https://domain.com/iredadmin

However, it keeps timing out with a 500 error.

I check my error log, and I see the following:

[Sat Apr 11 16:53:41 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 16:57:56 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 16:58:31 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:04:50 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:05:25 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 17:10:16 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:33:27 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:34:50 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py
[Sat Apr 11 18:40:38 2015] [error] [client IP.ADDRESS.GOES.HERE] Script timed out before returning headers: iredadmin.py

This has worked before, so I'm thinking that I've done something that breaks it. My guess is something related to SSL. I don't have SSL setup properly on my server - in fact that's why I was trying to access iRedAdmin - to add an email address for SSL confirmation. However this has absolutely worked before, so I'm not sure why it would stop working now.

I tried temporarily disabling IPTables to see if I could access it - but that didn't seem to be the issue (so my guess is that port 443 is not blocked).

Has anyone seen this error? What might be causing it? I can't find any documentation about the problem anywhere.

EDIT - additional requested information:

The script:

import os
import sys

rootdir = os.path.abspath(os.path.dirname(__file__))
sys.path.insert(0, rootdir)
from libs import iredbase

# Initialize webpy app.
app = iredbase.app

if __name__ != '__main__':
 # Run app under Apache + mod_wsgi.
 application = app.wsgifunc()
else:
 # Starting webpy builtin http server.
 app.run()

ifconfig:

eth0 Link encap:Ethernet HWaddr 04:01:17:63:25:01
 inet addr:162.243.99.103 Bcast:162.243.99.255 Mask:255.255.255.0
 inet6 addr: fe80::601:17ff:fe63:2501/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:157212578 errors:0 dropped:0 overruns:0 frame:0
 TX packets:23981088 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:13992866807 (13.9 GB) TX bytes:9214954428 (9.2 GB)

lo Link encap:Local Loopback
 inet addr:127.0.0.1 Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING MTU:16436 Metric:1
 RX packets:24601180 errors:0 dropped:0 overruns:0 frame:0
 TX packets:24601180 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:3826034358 (3.8 GB) TX bytes:3826034358 (3.8 GB)

Not sure precisely what you want me to ping - I am currently logged into the server where I am trying to access https on.

Do you need to see the contents of iredbase too?

There are two general approaches to solve script timeouts, you can either make the script faster, or bypass or extend the timeout. Everyone agrees that if you make the script faster it is better, but sometimes you can't or don't know how to. On public production scripts I would make every effort to make things fast enough not to timeout or goto a background processing mechanism (your request was received, we will have an answer for you in about an hour).

But in development and some classes of internal applications long requests are acceptable

There are three classes of timeouts that web servers impose on scripts.

1. total time to finish


2. progress timeout: this happens when the script sends some output, but stops.


3. first byte or all headers: If the webserver does not receive the headers to send them to the browser, the browser thinks the server is not responding and times out, so it makes sense for the webserver to kill the script when this becomes likely.

These are typically adjustable, but I would not adjust the first byte timeout, (because then the browser will timeout instead which solves nothing) but instead make an effort to not wait to send the headers. This can often be accomplished by either disabling output buffering from the script or by flushing the buffers at regular intervals. then by adding debugging output, you can see where you are actually spending your time.

I did note that the bulk of your application is not in your script, which makes it likely that the language startup (with includes) is too long to be practical, in which case something like mod_python or fast_cgi where the startup takes place prior to the request would be a good idea.