Ubuntu升级破解了django mod_wsgi

看起来，如果守护进程没有对其工作目录的权限，mod_wsgi将无法启动。 从源代码：

 if (wsgi_setup_access(daemon) == -1) { /* * If we get any failure from setting up the appropriate * permissions or working directory for the daemon process * then we exit the process. Don't die immediately to avoid * a fork bomb. */ ap_log_error(APLOG_MARK, APLOG_ALERT, 0, wsgi_server, "mod_wsgi (pid=%d): Failure to configure the " "daemon process correctly and process left in " "unspecified state. Restarting daemon process " "after delay.", getpid()); sleep(20); wsgi_exit_daemon_process(-1); } 

以防万一你还没有解决这个问题：

在mod_wsgi 2.0+中，如果使用WSGIDaemonProcess指令，则需要指定主目录。 在我的情况下，我正在使用一个没有主目录的用户，这导致了你看到的同样的错误。

家=目录

定义目录的绝对path，该目录应该用作进程组中守护进程的当前初始工作目录。 如果未定义此选项，则在mod_wsgi 1.X中，Apache父进程的当前工作目录将由进程组中的守护进程inheritance。 通常，Apache父进程的当前工作目录将是根目录。 在mod_wsgi 2.0+中，初始当前工作目录将被设置为守护进程运行的用户的主目录。

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

守护进程模式的当前工作目录周围的行为已经随时间而改变。

回到过去，无论Apache设置当前的工作目录将被使用。 这通常是'/'。

然后，它被修改为尝试使用守护进程运行的用户的工作目录。 如果这个用户没有一个有效的主目录，就像默认的Apache用户那样，它会默默的失败，你仍然会把它留在'/'中。

当作为与安全问题有关的清理的一部分进行了一些更改时，无声故障被删除，并且如果用户没有主目录，则无意中造成了硬错误。 这造成了问题，因为它没有意识到Apache用户有时没有一个有效的主目录。

这引发了进一步的变化，只有在守护进程运行的用户不是默认的Apache用户时才会使用主目录。 如果您将守护进程的用户明确设置为非Apache用户，并且没有主目录，则必须采取措施设置“主目录”选项。

因此，这听起来像你没有使用最新的mod_wsgi版本，而是一个具有倒数第二行为的版本。

由于一些Linux发行版向一些较旧版本的mod_wsgi版本移植了一些相关的修改，甚至当安全问题没有要求修改被移植时，它们也创造了一些混乱，因为他们从来没有拿到最后一次修改地址Apache用户没有主目录。

所以最终你的问题是由你的Linux发行版使用过时的mod_wsgi引起的，也可能是由于移植了一些不完整的修改。

您的解决方法是设置为WSGIDaemonProcess选项的home ='/'。

更好的是，升级到最新的mod_wsgi版本，而不是你的Linux发行版使用的古老版本。

最新版本的mod_wsgi 4.4.8。 您的Linux发行版本发布了超过20个版本，因此您错过了许多错误修复和改进。