在带有mod_wsgi的Apache上使用Django的网关超时

时间:2022-09-17 07:52:15

I'm having a problem getting Apache to reply properly. I'm getting a browser error: Gateway Timeout: The gateway did not receive a timely response from the upstream server or application.

让Apache正确回复我有问题。我收到一个浏览器错误:网关超时:网关没有收到来自上游服务器或应用程序的及时响应。

I know the application is connecting through mod_wsgi to the Django layer, as I've verified queries are occurring in PostgreSQL when the connection occurs, from the Wagtail CMS's middleware running.

我知道应用程序通过mod_wsgi连接到Django层,因为当连接发生时,从Wagtail CMS的中间件运行中,我已经验证了在PostgreSQL中发生的查询。

The system is running RHEL 7.1, Apache 2.4.6, and mod_wsgi 4.4.21 with Python 3.4 and Django 1.8.

系统使用Python 3.4和Django 1.8运行RHEL 7.1、Apache 2.4.6和mod_wsgi 4.21。

Here's the error in the Apache log:

Apache日志中的错误是:

[Thu Jan 07 13:25:54.554395 2016] [wsgi:error] [pid 17128] [client 128.91.91.123:50664] Timeout when reading response headers from daemon process 'my_classroom-https': /var/www/html/my_classroom/my_classroom/wsgi.py

Here's wsgi.py:

wsgi.py:

import os, sys
from socket import gethostname
from django.core.wsgi import get_wsgi_application

sys.path.append(os.sep.join(os.path.abspath(__file__).split(os.sep)[:-2]))

# cpl == Core, Production, Linux..
if(gethostname()[:3]) == 'cpl':
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_classroom.settings.prod")
# csl == Core, Staging, Linux.
elif(gethostname()[:3]) == 'csl':
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_classroom.settings.stage")
# else use dev settings.
# cdl == Core, Development, Linux. vag == Vagrant.
else:
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_classroom.settings.dev")

application = get_wsgi_application()

And here's the relevant portion of the Apache config:

这是Apache config的相关部分:

LoadModule wsgi_module modules/mod_wsgi.so
LoadModule ssl_module modules/mod_ssl.so

WSGISocketPrefix /var/run/wsgi

NameVirtualHost *:443
Listen 443
<VirtualHost *:443>

  ServerName my-python-dev.school.edu
  ErrorLog /var/www/logs/classroom-apache-errors.log

  SSLENGINE on

  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
  SSLProtocol all -SSLv2

  WSGIApplicationGroup %{GLOBAL}
  WSGIDaemonProcess my_classroom-https python-home=/var/www/virtualenvs/my_classroom request-timeout=600
  WSGIScriptAlias /classroom /var/www/html/my_classroom/my_classroom/wsgi.py process-group=my_classroom-https
  WSGIProcessGroup my_classroom-https
  Alias /classroom/static/ /var/www/html/my_classroom/static/

  LogLevel info
</VirtualHost>

I've tried a few few things, including increasing the request-timeout parameter of the WSGIDaemonProcess directive to be 600 seconds instead of 60, but it still seems to timeout right around 60 seconds.

我已经尝试了一些事情,包括将WSGIDaemonProcess指令的请求超时参数从60秒增加到600秒,但它似乎仍然在60秒左右超时。

Any ideas or help would be greatly appreciated. Thanks.

如有任何意见或帮助,我们将不胜感激。谢谢。

1 个解决方案

#1


1  

I got this working. The problem was a secondary database definition (not default) which couldn't connect to the server. There was no indication of this anywhere in the logs, unfortunately. This is a tough error to debug.

我得到了这个工作。问题是次要的数据库定义(不是默认的)不能连接到服务器。不幸的是,日志中没有任何迹象表明这一点。这是一个很难调试的错误。

Here's some steps I'd take next time I see this error:

下面是我下次看到这个错误时的一些步骤:

  • Take a very deep breath and relax!
  • 深呼吸,放松!
  • Confirm if any activity is happening in the database at all for the request.
  • 确认数据库中是否存在任何请求活动。
  • Make sure you can connect to all services needed by telnet (telnet mypostgresserver.domain.com 5432, telnet ldap.myprivate.network 636), and that they're not hanging.
  • 确保您可以连接到telnet所需的所有服务(telnet mypostgresserver.domain.com 5432, telnet ldap. myprivate.net636),并且它们不会挂起。
  • Modify the settings files, excluding anything possible (middleware, optional apps, backends other than ModelBackend, etc)
  • 修改设置文件,排除任何可能的情况(中间件、可选应用程序、模型后端以外的后端等)
  • Failing that, start commenting out segments of the settings files, to see if you can get a less cryptic response.
  • 如果做不到这一点,请开始注释设置文件的片段,以查看是否可以获得更少的神秘响应。

#1


1  

I got this working. The problem was a secondary database definition (not default) which couldn't connect to the server. There was no indication of this anywhere in the logs, unfortunately. This is a tough error to debug.

我得到了这个工作。问题是次要的数据库定义(不是默认的)不能连接到服务器。不幸的是,日志中没有任何迹象表明这一点。这是一个很难调试的错误。

Here's some steps I'd take next time I see this error:

下面是我下次看到这个错误时的一些步骤:

  • Take a very deep breath and relax!
  • 深呼吸,放松!
  • Confirm if any activity is happening in the database at all for the request.
  • 确认数据库中是否存在任何请求活动。
  • Make sure you can connect to all services needed by telnet (telnet mypostgresserver.domain.com 5432, telnet ldap.myprivate.network 636), and that they're not hanging.
  • 确保您可以连接到telnet所需的所有服务(telnet mypostgresserver.domain.com 5432, telnet ldap. myprivate.net636),并且它们不会挂起。
  • Modify the settings files, excluding anything possible (middleware, optional apps, backends other than ModelBackend, etc)
  • 修改设置文件,排除任何可能的情况(中间件、可选应用程序、模型后端以外的后端等)
  • Failing that, start commenting out segments of the settings files, to see if you can get a less cryptic response.
  • 如果做不到这一点,请开始注释设置文件的片段,以查看是否可以获得更少的神秘响应。