Ubuntu 500 上的烧瓶/nginx/gunicorn 中的 NLTK+TextBlob 错误答案

【问题标题】：NLTK+TextBlob in flask/nginx/gunicorn on Ubuntu 500 errorUbuntu 500 上的烧瓶/nginx/gunicorn 中的 NLTK+TextBlob 错误
【发布时间】：2014-11-12 17:57:12
【问题描述】：

我正在尝试在 Ubuntu 上运行的 Flask 应用程序中运行名词短语分析，通过 gunicorn 和 nginx 提供服务。我收到一个错误 500，在 nginx、supervisor 或 unicorn 错误日志中没有（明显）记录错误。 “supervisorctl tail app”也没有任何启示。

我的站点可用 nginx.conf：

server {
    listen 80;
    server_name [domain redacted];
    charset utf-8;
    client_max_body_size 75M;

    access_log /var/log/nginx/nginx_access.log;
    error_log /var/log/nginx/nginx_error.log;

    location / { try_files $uri @app; }

    location @app {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

我的主管 app.conf

[program:app]
command = gunicorn app:app -b localhost:8000
directory = /home/www/app
user = admin

我正在 app.py 中运行我的应用程序，使用以下内容（在 config.py 中遇到 DEBUG = False 和 True 的问题）

app = Flask(__name__, static_folder='static', static_url_path='/static')
app.config.from_pyfile('config.py')

if __name__ == '__main__':
        app.run()
        if not app.debug:
            stream_handler = logging.StreamHandler()
            stream_handler.setLevel(logging.INFO)
            app.logger.addHandler(stream_handler)

Config.py 很简单

DEBUG = False
ALLOWED_HOSTS=['*']

我调用的名词短语函数

from textblob import TextBlob

def generateNounPhrases(input):
    blob = TextBlob(input)
    np = blob.noun_phrases

    return np

页面的app.py烧瓶路由，传递generateNounPhrases()的输出

@app.route('/thread', methods=['GET'])
def thread():
    ...
    nounphrases = generateNounPhrases(text_to_analyze)   
    ...

    return render_template("Thread.html", nounphrases=nounphrases)

我完全迷失了，在这方面绝对是新手。任何指导都会很棒！

【问题讨论】：

如果你设置DEBUG = True会发生什么？
我看到一个“内部服务器错误”页面与我在 False 下收到的标准 500 页面略有不同。否则，我看不到任何不同。我希望它会触发我在本地开发时习惯的 Werkzeug 错误屏幕，但不是这样。

标签： ubuntu flask nltk textblob

【解决方案1】：

app.conf 主管文件中声明的 sudo user = admin 是为运行此应用而创建的，但无法在站点根级别读取。在 /root/nltk_data 下载的无法访问的 NLTK 语料库导致我原来的 500...

我在重新配置 gunicorn 日志记录后发现了这个问题，并在 supervisorctl restart app 上接收到致命的主管崩溃，因为新指出的 gunicorn.log 没有写入权限。

我更新和工作的主管配置，没有用户声明，如下：

[program:app]
command = gunicorn app:app -b localhost:8000 --log-file /var/log/gunicorn/gunicorn_log.log
directory = /home/www/app
stdout_logfile=/var/log/supervisor/supervisor_stdout.log
stderr_logfile=/var/log/supervisor/supervisor_stderr.log

但是，我不确定此配置的完整安全含义是什么，也不确定为什么 sudo 组管理员用户没有正确访问目录。任何有这个答案的人都会得到奖励。

【讨论】：