0

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?

2
  • So many things you haven't told us that are necessary to understand the problem. It's as if you brought your car to the mechanic, told them it wouldn't start, and asked them to fix it without being able to look under the hood. We would need to see full contents of the script, the command you used to run it, and output of several commands, including ifconfig and a ping for starters. Commented Apr 11, 2015 at 19:09
  • I considered posting the script as well. I'll do that now. Commented Apr 11, 2015 at 19:17

1 Answer 1

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .