Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Finally I have solved this problem after working nearly 2 days on it. I hope this solution will help other flask/uwsgi users that are experiencing a similar problem.</p> <p>I had two major issues that caused this.</p> <p>1) The best way to find the problems with a daemon is obviously a log file and a cleaner structure.</p> <p><code>sudo vim /etc/init/uwsgi.conf</code></p> <p>Change the daemon script to the following:</p> <pre><code># 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 </code></pre> <p><code>vim /myproject/uwsgi.ini</code></p> <pre><code>[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 </code></pre> <p>This is much cleaner way of setting up the daemon. Also notice the last line how to setup the log file. Initially I had set the log file to <code>/var/log/uwsgi/error.log</code>. After a lot of sweat and tears I realized the daemon is running as <code>www-data</code> and hence can not access the <code>/var/log/uwsgi/error.log</code> since the error.log was owned by <code>root:root</code>. This made the uwsgi fail silently. </p> <p>I found it much more efficient to just point the log file to my own <code>/myproject</code>, where the daemon has guaranteed access as <code>www-data</code>. And also don't forget to make the whole project accessible to <code>www-data</code> or the daemon will fail with an <code>Internal Server error message</code>. --> </p> <pre><code>sudo chown www-data:www-data -R /myproject/ </code></pre> <p>Restart uwsgi daemon:</p> <pre><code>sudo service uwsgi restart </code></pre> <p>2) Now you have three log files to lookout for:</p> <ul> <li><p><code>tail -f /var/log/upstart/uwsgi.log</code> --> Shows problems with your daemon upon start</p></li> <li><p><code>tail -f /var/log/nginx/error.log</code> --> Shows permission problems when wsgi access is refused, often because <code>/tmp/uwsgi.sock</code> file is owned by <code>root</code> instead of <code>www-data</code>. In that case simply delete the sock file <code>sudo rm /tmp/uwsgi.sock</code></p></li> <li><p><code>tail -f /myproject/error.log</code> --> Shows errors thrown by uwsgi in your application</p></li> </ul> <p>This combination of log files helped me to figure out that I also had a bad import with Flask-Babel in my Flask application. Bad in that sense, that the way I utilized the library was falling back to the system's locale to determine the datetime format.</p> <pre><code>File "/myproject/F11/Engineering/f11_app/templates/show_records.html", line 25, in block "body" &lt;td&gt;{{ record.record_date|format_date }}&lt;/td&gt; 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' </code></pre> <p>This is the way I was using the Flask filter:</p> <pre><code>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)) </code></pre> <p>The strangest part is that this code is working perfectly fine within the dev environment (!). It works even fine when running the uwsgi as a root process from the command line. But it fails when ran by the www-data daemon. This must have something to do with how the locale is set, which Flask-Babel is trying to fall back to.</p> <p>When I changed the import like this, it all worked finally with the daemon:</p> <pre><code>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)) </code></pre> <p>Hence be careful when using Eclipse/Aptana Studio that is trying to pick the right namespace for your classes in code. It can really turn ugly.</p> <p>It is now working perfectly fine as a uwsgi daemon on an Amazon Ec2 (Ubuntu 12.04) since 2 days. I hope this experience helps fellow python developers.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload