Roberto De Ioris | 26 Mar 08:08 2015
Picon

experimental integration with rust

This is only a proof of concept, but should be a good starting point too

https://github.com/unbit/uwsgi-rust

Regards

--
Roberto De Ioris
http://unbit.com
Murat Knecht | 26 Mar 04:02 2015

Default Log Format Explained?

Hello,

could somebody tell me whether the default log format is explained
somewhere? I.e. the exact meanings of the numbers and other data in
lines such as:

    [pid: 596|app: 0|req: 24/72] 222.127.73.32 () {50 vars in 1043
bytes} [Wed Jan 14 11:44:29 2015] POST /countries/ => generated 2 bytes
in 149 msecs (HTTP/1.1 200) 3 headers in 112 bytes (1 switches on core 0)

I can make some educated guesses, of course, but would rather not have to.

I have read the section in the documentation [1], which lists the
available options, and found the mail in the archive announcing the
log-format option [2] (cheers for that :) ). In the Git repository I
found the code where the log line is assembled [3], but since it does
not simply use the documented variables, it's not directly documenting
itself. Before I start digging in the code, did I miss the docs?

If not, I'd try to come up with a patch for the documentation. Does that
make sense?

Cheers,
murat

[1] https://uwsgi-docs.readthedocs.org/en/latest/LogFormat.html
[2] http://lists.unbit.it/pipermail/uwsgi/2012-July/004463.html
[3] https://github.com/unbit/uwsgi/blob/master/core/logging.c#L715
Tim Tisdall | 20 Mar 17:57 2015
Picon

ugreen not returning from uwsgi.suspend() on second request

I'm not really sure how to get any more information on this to help
with debugging, but what's happening is my worker process freezes when
it's just finished running uwsgi.suspend() and another request comes
into uwsgi.  I see my logging statement just before the
uwsgi.suspend(), but after another http request comes in there's no
more messages even if there's content on that socket it's suspending
on.  The next message I get after some time in the HARAKIRI one.

What's strange is I'm running similar code on another machine and it
seems to be working fine on there.  I did see similar failures, but
after it's been running for a while they seem to have gone away.

Is there any way to get additional logging for uwsgi to see where it's
locking up?
Jerry OELoo | 20 Mar 02:54 2015
Picon

How to deploy script and library

Hi.
I have using uWSGI for my web service, it will load some python script
and python script will load some so library file.
When I fix some bug, I will replace py and so files, and use command
line uWSGI --reload parameter to ask uWSGI restart to load updated
files. It works.

Now I have a question about that if my web service is working as 7*24,
it will receive request at any time, So what is proper way to update
my code (py and so files)? Is there any risk that I use --reload
parameter directly? Thanks!

Best Regards
Jerry

--

-- 
Rejoice,I Desire!
Roberto De Ioris | 17 Mar 09:05 2015
Picon

[ANNOUNCE] uWSGI 2.0.10


Little bugfix release:

http://uwsgi-docs.readthedocs.org/en/latest/Changelog-2.0.10.html

Regards

--

-- 
Roberto De Ioris
http://unbit.com
Manivel Rajendran | 17 Mar 07:06 2015
Picon

Nginx + Uwsgi Can't download large file ( more the 1GB)

Hello,

I am trying to download a large file from my webserver, The file size is around 2.5GB. When I try to download it via the browser it's not download completely, after 1GB automatically truncate ( Nginx + uwgi website ) but i can able to download full when i will use without uwsgi.



Best Regards
Manivel


_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Mikko Ohtamaa | 14 Mar 02:59 2015

Re: Workers hanging due to FUTEX_WAIT_PRIVATE


Hi,

Any thoughts on how I can go about tracking down the cause of this issue?

Not sure if somebody already mentioned this, but use Tracebacker to take Python thread dump from hung server:

http://uwsgi-docs.readthedocs.org/en/latest/Tracebacker.html

-Mikko
 

--
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Tim Tisdall | 13 Mar 17:49 2015
Picon

harakiri with ugreen

I have setting "harakiri = 60" set.  I'm using ugreen so I have
multiple async cores per worker.  I'm guessing there's separate timers
per "core", but it seems like it kills the whole worker process.
Maybe it's not practical to just kill a core and context switch out,
or maybe it's trying that and failing, I'm not really sure how it's
working.  However, is there any way to tell which core's timer tripped
the harakiri?  I suspect it's which ever line has the oldest "since
[timestamp]"?

Here's my logs:

Fri Mar 13 16:23:28 2015 - *** HARAKIRI ON WORKER 2 (pid: 20648, try: 1) ***
Fri Mar 13 16:23:28 2015 - HARAKIRI !!! worker 2 status !!!
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 178] 208.90.100.6 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A19%3A14.329000%2B0000&count=3
since 1426263775
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 179] 208.90.101.56 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A23%3A11.076000%2B0000&count=3
since 1426263793
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 183] 130.63.114.112 - POST
/sitrep_json?timestamp=2015-03-13T16%3A22%3A43.778000%2B0000&count=3
since 1426263772
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 185] 208.90.101.206 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A21%3A51.968000%2B0000&count=3
since 1426263769
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 186] 208.90.100.6 - POST
/walldisplay_json?timestamp=2015-03-13T14%3A13%3A43.594000%2B0000&count=1
since 1426263768
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 187] 208.90.101.12 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A21%3A16.535000%2B0000&count=3
since 1426263781
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 188] 208.90.100.6 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A19%3A14.329000%2B0000&count=3
since 1426263772
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 189] 130.63.114.112 - POST
/login since 1426263808
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 191] 208.90.101.12 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A19%3A04.271000%2B0000&count=3
since 1426263795
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 192] 208.90.101.206 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A23%3A20.857000%2B0000&count=1
since 1426263801
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 193] 208.90.101.192 - POST
/walldisplay_json?timestamp=2015-03-13T14%3A13%3A43.594000%2B0000&count=1
since 1426263771
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 194] 208.90.101.192 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A23%3A02.528000%2B0000&count=3
since 1426263784
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 195] 208.90.101.192 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A09%3A17.970000%2B0000&count=3
since 1426263773
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 196] 208.90.101.12 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A21%3A16.535000%2B0000&count=3
since 1426263780
Fri Mar 13 16:23:28 2015 - HARAKIRI [core 198] 208.90.100.6 - POST
/walldisplay_json?timestamp=2015-03-13T16%3A22%3A43.778000%2B0000&count=3
since 1426263771
Fri Mar 13 16:23:28 2015 - HARAKIRI !!! end of worker 2 status !!!
DAMN ! worker 2 (pid: 20648) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 21832)
Roberto De Ioris | 13 Mar 14:30 2015
Picon

Re: Workers hanging due to FUTEX_WAIT_PRIVATE


> Every couple of minutes, I end up with a worker that gets stuck busy.
> strace shows that this worker is blocked by:
>
> futex(0x4dc7d08, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
>
> Harakiri will ultimately kill the worker after 300 seconds as configured
> in
> the ini file.
>
> Any thoughts on how I can go about tracking down the cause of this issue?
>
>
> Configuration info follows...
>
> This happens on multiple AWS instances, all configured the same way:
>
> Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64
> GNU/Linux
>
> I am running the 2.0.9 version of uwsgi (installed via pip).
>
> My ini file is:
>
> [uwsgi]
> chdir = /opt/site/project/
> master = true
> wsgi-file = /opt/site/project/app/wsgi.py
> processes = 10
> stats = 127.0.0.1:9191
> socket = 127.0.0.1:3031
> uid = www-data
> gid = www-data
> vacuum = True
> enable-threads = false
> env = DJANGO_SETTINGS_MODULE=app.settings
> env = ENVIRONMENT=project
> home = /opt/site/project/
> virtualenv = /opt/site/project/.venv/
> daemonize = /var/log/uwsgi.log
> single-interpreter = true
> maxrequests = 200
> reload-on-as = 256
> idle = 300
> harakiri = 300
>
>

futex is the main linux locking primitive. Probably some part of your code
uses threads so it needs to manage locking/GIL. Try setting enable-threads
to true

--

-- 
Roberto De Ioris
http://unbit.com
Jimmy Gawain | 13 Mar 14:09 2015
Picon

Workers hanging due to FUTEX_WAIT_PRIVATE

Every couple of minutes, I end up with a worker that gets stuck busy. strace shows that this worker is blocked by:

futex(0x4dc7d08, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>

Harakiri will ultimately kill the worker after 300 seconds as configured in the ini file.

Any thoughts on how I can go about tracking down the cause of this issue?


Configuration info follows...

This happens on multiple AWS instances, all configured the same way:

Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

I am running the 2.0.9 version of uwsgi (installed via pip).

My ini file is:

[uwsgi]
chdir = /opt/site/project/
master = true
wsgi-file = /opt/site/project/app/wsgi.py
processes = 10
socket = 127.0.0.1:3031
uid = www-data
gid = www-data
vacuum = True
enable-threads = false
env = DJANGO_SETTINGS_MODULE=app.settings
env = ENVIRONMENT=project
home = /opt/site/project/
virtualenv = /opt/site/project/.venv/
daemonize = /var/log/uwsgi.log
single-interpreter = true
maxrequests = 200
reload-on-as = 256
idle = 300
harakiri = 300

I am using python 2.7, Django 1.6, with the following packages:

django-extensions==1.3.11
Django==1.6.1
wsgiref==0.1.2
coverage==3.7.1
flake8==2.1.0
psycopg2==2.5.2
South==0.8.2
django-debug-toolbar==1.0.1
hashids==0.8.3
radon==0.4.4
pytz==2013b
djangorestframework==2.3.12
django-filter==0.7
django-autocomplete-light==2.0.0a15
django-countries==2.0
python-dateutil==2.2
numpy==1.8
Pillow==2.3.1
html5lib==0.999
httplib2==0.9
pyPdf2==1.23
reportlab==2.7
xhtml2pdf==0.0.6
boto==2.29.1
django-storages==1.1.8
django-adminactions==0.6
django-import-export==0.2.6
pycrypto==2.6.1

thanks.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Bill Masters | 13 Mar 11:20 2015
Picon

Nginx support + Static files + docs improvements

Hello.

In https://uwsgi-docs.readthedocs.org/en/latest/Nginx.html#static-files we have nginx configuration example:

location /media { alias /var/lib/python-support/python2.6/django/contrib/admin/media; }

According to http://nginx.org/en/docs/http/ngx_http_core_module.html#alias

When location matches the last part of the directive’s value:

location /images/ { alias /data/w3/images/; }

it is better to use the root directive instead:

location /images/ { root /data/w3; }
It would be great to improve nginx configuration examples for the following links:

01. https://uwsgi-docs.readthedocs.org/en/latest/Nginx.html#static-files ('location /media')
02. https://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html#configure-nginx-for-your-site ('location /media' + 'location /static')

Thanks.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Gmane