debugging uwsgi

Robin Becker robin at reportlab.com
Fri Jan 8 11:49:34 EST 2016


On 08/01/2016 15:03, Robin Becker wrote:
> I have an unusual bug in a large django project which has appeared when using
> nginx + uwsgi + django. The configuration nginx + flup + django or the django
> runserver don't seem to create the conditions for the error.
>
> Basically I am seeing an error
>
>> Traceback (most recent call last):
>> File "./project/fundfacts/api.py", line 33, in refresh_data
>> call_command('fe_data_load', month=period_id, datadir=upload_dir)
>> File
>> "/home/rptlab/website/quilter.reportlab.com/quilter_2/lib/python2.7/site-packages/django/core/management/__init__.py",
>> line 105, in call_command
>> command = load_command_class(app_name, name)
>> File
>> "/home/rptlab/website/quilter.reportlab.com/quilter_2/lib/python2.7/site-packages/django/core/management/__init__.py",
>> line 40, in load_command_class
>> module = import_module('%s.management.commands.%s' % (app_name, name))
>> File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
>> __import__(name)
>> ImportError: No module named fe_data_load
..........
I discovered by trial and error that a preceding call_command had caused a 
chdir; that seems to have deleterious effects on the uwsgi process in question.

I'm not sure why the flup server is superior, but I guess something must be 
different about the python startup used by uwsgi compared to python manage.py 
runfcgi.

I'm still interested to find out any sensible way to debug uwsgi + python.
-- 
Robin Becker




More information about the Python-list mailing list