最後に、2日近く作業した後、この問題を解決しました。この解決策が、同様の問題を経験している他のフラスコ/uwsgi ユーザーに役立つことを願っています。
これを引き起こした2つの大きな問題がありました。
1) デーモンの問題を見つける最善の方法は、明らかにログ ファイルとよりクリーンな構造です。
sudo vim /etc/init/uwsgi.conf
デーモン スクリプトを次のように変更します。
# file: /etc/init/uwsgi.conf
description "uWSGI server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /home/ubuntu/uwsgi-1.9.12/uwsgi -c /myproject/uwsgi.ini
vim /myproject/uwsgi.ini
[uwsgi]
socket = /tmp/uwsgi.sock
master = true
enable-threads = true
processes = 5
chdir= /myproject/F11/Engineering
module=F11:app
virtualenv = /myproject/myproject-env/
uid = www-data
gid = www-data
logto = /myproject/error.log
これは、デーモンをセットアップするためのよりクリーンな方法です。また、ログ ファイルのセットアップ方法の最後の行にも注目してください。最初に、ログ ファイルを/var/log/uwsgi/error.log. 多くの汗と涙の後、私はデーモンが として実行されていることにwww-data気付き/var/log/uwsgi/error.logましたroot:root。これにより、uwsgi が静かに失敗しました。
デーモン/myprojectがwww-data. また、プロジェクト全体にアクセスできるようにすることを忘れないでください。そうしないとwww-data、デーモンがInternal Server error message. -->
sudo chown www-data:www-data -R /myproject/
uwsgi デーモンを再起動します。
sudo service uwsgi restart
2) これで、3 つのログ ファイルを確認できます。
tail -f /var/log/upstart/uwsgi.log --> 起動時のデーモンの問題を表示します
tail -f /var/log/nginx/error.log --> wsgi アクセスが拒否された場合のパーミッションの問題を示します。多くの場合、ファイルはではなく/tmp/uwsgi.sockによって所有されているためです。その場合は、単に sock ファイルを削除しますrootwww-datasudo rm /tmp/uwsgi.sock
tail -f /myproject/error.log --> アプリケーションで uwsgi によってスローされたエラーを表示します
このログ ファイルの組み合わせは、Flask アプリケーションで Flask-Babel を使用した場合のインポートにも問題があることを理解するのに役立ちました。その意味で、私がライブラリを利用した方法は、日時形式を決定するためにシステムのロケールにフォールバックしていたことです。
File "/myproject/F11/Engineering/f11_app/templates/show_records.html", line 25, in block "body"
<td>{{ record.record_date|format_date }}</td>
File "./f11_app/filters.py", line 7, in format_date
day = babel_dates.format_date(value, "EE")
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 459, in format_date
return pattern.apply(date, locale)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 702, in apply
return self % DateTimeFormat(datetime, locale)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 699, in __mod__
return self.format % other
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 734, in __getitem__
return self.format_weekday(char, num)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 821, in format_weekday
return get_day_names(width, context, self.locale)[weekday]
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 69, in get_day_names
return Locale.parse(locale).days[context][width]
AttributeError: 'NoneType' object has no attribute 'days'
これは、Flask フィルターを使用していた方法です。
import babel.dates as babel_dates
@app.template_filter('format_date')
def format_date(value):
day = babel_dates.format_date(value, "EE")
return '{0} {1}'.format(day.upper(), affix(value.day))
最も奇妙な部分は、このコードが開発環境内で完全に正常に機能していることです (!)。コマンド ラインからルート プロセスとして uwsgi を実行すると、問題なく動作します。しかし、www-data デーモンで実行すると失敗します。これは、Flask-Babel がフォールバックしようとしているロケールの設定方法と関係があるはずです。
このようにインポートを変更すると、デーモンで最終的にすべてが機能しました。
from flask.ext.babel import format_date
@app.template_filter('format_date1')
def format_date1(value):
day = format_date(value, "EE")
return '{0} {1}'.format(day.upper(), affix(value.day))
したがって、コード内のクラスに適切な名前空間を選択しようとしている Eclipse/Aptana Studio を使用する場合は注意してください。それは本当に醜いものになる可能性があります。
2 日以来、Amazon Ec2 (Ubuntu 12.04) で uwsgi デーモンとして完全に正常に動作しています。この経験が仲間の Python 開発者に役立つことを願っています。