更改wsgi脚本文件后,WSGI进程将不会重新加载

时间:2013-08-06 10:26:43

标签: django apache mod-wsgi

我在Apache2.2上运行Django站点,在守护进程模式下使用mod_wsgi 3.3(在Debian Wheezy上)。

当我从我的shell中使用touch wsgi.py命令到我的WSGI脚本时,重新加载进程并且一切正常。但是,当我从Web应用程序代码修改wsgi.py文件时,修改时间被正确更改(由stat检查)但WSGI进程未重新启动。我在手动触摸文件时使用相同的用户帐户,因为WSGI-daemon在。

下运行

我尝试了以下两种方法从网络应用程序代码“触摸”文件,但没有一种方法有效:

  1. os.system('touch /abs/path/to/wsgi.py')
  2. 使用django-rosetta的ROSETTA_WSGI_AUTO_RELOAD设置为我完成这项工作
  3. 上面的两个选项实际上看起来完全像我从shell手动执行touch时那样。他们更新了所有访问,修改和更改文件属性(我正在使用ext4,如果这可能很重要)。

    我知道这是一种非常奇怪的行为,在我阅读完所有文档之后,我无望。有没有人至少知道可能是什么原因?

2 个答案:

答案 0 :(得分:2)

请注意,重新加载仅发生在Web应用程序收到的下一个请求中。在触摸wsgi.py文件时,它不是即时的。虽然您似乎认为这不是问题,但Apache通常也会作为特殊用户运行,并且无法修改WSGI脚本文件,除非您专门设置了允许它的权限。

为了更好地确定发生了什么,请确保在Apache配置中将LogLevel设置为info,并查看mod_wsgi在Apache错误日志中生成的日志消息。

有关触发重新加载的更多详细信息和其他方法,请参阅:

答案 1 :(得分:1)

好吧,终于找到了解决方案。我正在使用自定义中间件更改某些URL的区域设置。但是,中间件在请求(translation.deactivate()方法)结束时没有调用process_response,这显然导致了一些奇怪的线程间共享的语言环境选择,从而影响了所有进一步的请求。只有当中间件在进程启动后更改了第一个请求的语言环境时才会发生这种情况。

此处有更多信息:set language within a django view