Thomas Larsen Wessel | 19 Dec 11:42 2014
Picon

pip uninstall uwsgi, leaves /usr/local/bin/uwsgi

I guess this is a bug, or what? And I could not figure out where to report it, so now I'm trying here.

It caused me some headache. I was in a virtualenv with a uwsgi installation, I uninstalled it from the virtualenv, but the local executable uwsgi remained. So when I thought I was running the global, I was running the local, which meant unexpected values for home and cwd (I think).
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Simon | 15 Dec 22:10 2014
Picon

uwsgi c-ares plugin build error

I get this error while building the c-ares plugin:

[gcc -pthread] cares_plugin.so
/uwsgi-cares/dns.c: In function 'cares_register':
/uwsgi-cares/dns.c:191:12: error: dereferencing pointer to incomplete type
*** unable to build cares plugin ***

I'm building inside a docker container running debian-wheezy and libc-ares-dev is installed. Uwsgi version is 2.0.8.

/simon
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Roberto De Ioris | 12 Dec 06:56 2014
Picon

implemented uwsgi::opt in perl


Hi, the perl/psgi plugin now exposes the uwsgi::opt hashref that contains
all the options set in the current instance:

$VAR1 = {
          'logdate' => '%d',
          'master' => 1,
          'psgi' => 'foo.pl',
          'http-socket' => [
                             ':9090',
                             ':9091',
                             ':9092'
                           ],
          'socket' => [
                        ':3034',
                        ':3035'
                      ],
          'processes' => '2'
        };

The patch has been applied to both master and uwsgi-2.0 (will be in 2.0.9)

https://github.com/unbit/uwsgi/commit/b59294db89c477d04624fa344c8b9b15435bebd0

Regards

--

-- 
Roberto De Ioris
http://unbit.com
Jean-Baptiste Quenot | 8 Dec 16:52 2014

Content-Length woes between uwsgi/php and nginx

Hello fellow UWSGI supporters,

I'm struggling with an issue in my PHP software (namely Pimcore).

The PHP stuff is served through an Haproxy -> Nginx -> UWSGI stack that runs without a hitch since 18 months.

A few days ago, after a Pimcore software update to version 2.3.0, users reported corrupted file downloads, and I noticed something weird with Content-Length.  Let me illustrate the problem with an example from the logs.

From uwsgi logs:

[pid: 15215|app: -1|req: -1/15] 127.0.0.1 () {32 vars in 567 bytes} [Mon Dec  8 14:58:50 2014] GET /admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true => generated 13950 bytes in 4364 msecs (HTTP/1.1 200) 8 headers in 256 bytes (0 switches on core 0)

From nginx logs:

127.0.0.1 - - [08/Dec/2014:14:58:54 +0100] "GET /admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true HTTP/1.1" 200 12032 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"

As you can see there is a discrepancy between the response length reported by uwsgi, and the one from nginx.  It should be the same.

The output of curl is also surprising:

curl -i -b pimcore_admin_sid=something http://localhost/admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Mon, 08 Dec 2014 13:58:54 GMT
Content-Type: image/pjpeg
Content-Length: 2
Connection: keep-alive
Content-Disposition: attachment; filename="320.336g-1.pjpeg"
Cache-Control: public, max-age=300
Expires: Mon, 08 Dec 2014 15:03:54 +0100
Pragma:
X-Powered-By: pimcore


As you can see the reported Content-Length this time is 2 bytes!  And please notice there are two blank lines in the response.

How is it possible that the Content-Length is different in three places?

I couldn't find a way to make this problem 100% reproducible, so this is particularly difficult to resolve.

Your help would be appreciated to narrow down what is causing this.

UWSGI config file: https://gist.github.com/jbq/6840da7bb0e5de1fff85
Nginx config file: https://gist.github.com/jbq/76ebfd526f2ba8b60166

Best regards,
--
Jean-Baptiste Quenot


_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Manivel Rajendran | 4 Dec 07:52 2014
Picon

nginx+uwsgi+django, there seems to be some strange cache in uwsgi

Hi,
      The django works fine, but modified pages can't be seen unless i restart uwsgi. i didn't config anything about cache.

      It works well with "python manager runserver", but have this problem when working with nginx+uwsgi.

      This is my "uwsgi.ini" file

[uwsgi]
socket=/var/run/uwsgi/test_uwsgi.sock
virtualenv=/test/django_test/test_virtualenv
chdir=/test/django_test/test
module=test.wsgi:application
uid=apache
gid=apache
master=True
workers=8
pidfile=/test/django_test/test/uwsgi-master.pid
max-requests=5000
daemonize=/var/log/uwsgi/django_test.log

     Kindly help me.

Thanks & Regards

Manivel Rajendran

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Jacob Rief | 3 Dec 10:46 2014
Picon

Routing to websocket using a named unix socket

Unfortunately I'am unable to get uWSGI's router, proxying my websocket request to a uWSGI instance listening on a named unix socket.

In my configuration I have an emperor spawning two vassals. One vassal serves normal Django requests, while the other vassal serves Websockets requests. They both own a separate named Unix socket.

Currently nginx forwards requests to these two sockets and this works fine. The nginx configuration inside a server section looks like this:

server {
    ....

    location / {
        include /opt/local/etc/nginx/uwsgi_params;
        uwsgi_pass unix:/var/tmp/django.socket;
    }

    location /ws/ {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://unix:/var/tmp/web.socket;
    }
}

Now I wanted to replace nginx by uWSGI itself and use its own routing mechanism. For normal web requests this works fine and inside my configuration I have

[uwsgi]emperor = vassals

http-socket = :9090

#no-orphans = true

#threads = 1

#die-on-term = true

http-websockets = true

route = ^/ws http:unix:/var/tmp/web.socket

route = ^/ uwsgi:/var/tmp/django.socket,0,0


_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Gheorghe Chirica | 3 Dec 10:44 2014
Picon

Multiple cache from php

Hi.

I see that multiple caches is possible in uWSGI. Now, I want to define 2(or more) caches with different configs(mostly related to the size of a blocksize). How can we specify which cache we are using via api? And if we define 2 caches, which will be used by default? First declared in config?




Thx.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
James Vann | 25 Nov 20:22 2014

Chained Certificates

Hi!  I have successfully deployed my Django app using uWSGI.  I really
like useing it so far, just wish the documentation was better :)
Perhaps I will be able to make my own contributions to this area in
the future :)

Anyway, i am trying to secure my site with a HTTPS.  I found the
documentation on this, got my certificate signed, and tried to install
it.  However, my certificate is a chained certificate- and the docs
don't seem to mention this use case at all.

I tried:
https = :4443,intermediate.crt,temple.crt,temple.key,HIGH
and:
https = :4443,temple.crt,temple.key,HIGH
and:
https = :4443,temple.crt,intermediate.crt,temple.key,HIGH

and with every variation, i got:

[uwsgi-ssl] unable to assign certificate intermediate.crt for context
"http-:4443"
or:
[uwsgi-ssl] unable to assign certificate temple.crt for context "http-:4443"

Further details:
Ubuntu 14.04.1
Intel i5 64bit CPU
uwsgi is my webserver
uwsgi version 2.07

Let me know if you need anything else :)  Thanks so much!
Gheorghe Chirica | 22 Nov 16:06 2014
Picon

Map routes rules python functions

Hi.

I'm trying to create a simple test app using routing. What I want to accomplish is the following:
- have a list of rules defined.
- each rule map to specific python func
- when rules is matched, call the func(possible pass the params from matching rule $1, $2...)

I found some old, dusty docs, but seems that uwsgi.fastfuncs is no more supported.
 
Can you guid how to accomplish this? I know this is possible. Why? Well in uWSGI all is possible :).


Thx.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Jody McIntyre | 21 Nov 20:39 2014

Server hangs after harakiri; debugging harakiri events in general

Hi,

Our uWSGI server hangs (stops serving any requests until it's
restarted) about once a week, generally after a harakiri event.  Can
anyone help troubleshoot this?  Also how can I debug harakiri events
in general?  Most of them don't cause the server to hang, but I don't
understand what's causing them.  The requests printed when the worker
dies are all normal parts of our app that are accessed hundreds of
times per day without incident.

uWSGI version is 2.0.8.
OS is Ubuntu 14.04 LTS.
CPU is x86_64 - Intel(R) Xeon(R) CPU E5-2670 v2  <at>  2.50GHz on Amazon EC2.
Webserver is nginx, load balancer is haproxy.

Config is below.

Logs from a harakiri that caused the server to hang:

Thu Nov 20 15:09:29 2014 - *** HARAKIRI ON WORKER 8 (pid: 5046, try: 1) ***
HARAKIRI: -- syscall> 7 0x7fffafe0e9c0 0x1 0xffffffff 0x8 0x1040bc8
0x1 0x7fffafe0e9a0 0x7f3afea6cfbd
HARAKIRI: -- wchan> poll_schedule_timeout
Thu Nov 20 15:09:29 2014 - HARAKIRI !!! worker 8 status !!!
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 0] 127.0.0.1 - GET
/acct_quota since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 1] 127.0.0.1 - POST /pullf/
since 1416495854
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 2] 127.0.0.1 - GET / since 1416495861
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 3] 127.0.0.1 - GET / since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 4] 127.0.0.1 - POST /signin/
since 1416495865
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 5] 127.0.0.1 - POST
/clientresp since 1416495856
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 6] 127.0.0.1 - POST /pullf/
since 1416495858
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 7] 127.0.0.1 - GET
/~Dreamshot/495/percentage-of-bachelors-degrees-conferred-to-women-in-the-usa-by-major-1970-2012/
since 1416495852
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 8] 127.0.0.1 - POST
/stylethemes/ since 1416495858
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 9] 127.0.0.1 - POST
/clientresp since 1416495854
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 10] 127.0.0.1 - POST
/clientresp since 1416495856
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 11] 127.0.0.1 - GET
/acct_quota since 1416495860
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 12] 127.0.0.1 - POST
/signin/ since 1416495866
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 13] 127.0.0.1 - POST
/clientresp since 1416495865
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 14] 127.0.0.1 - POST /pullf/
since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 15] 127.0.0.1 - GET
/%7Ehianalytics/189/ since 1416495852
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 16] 127.0.0.1 - POST /pullf/
since 1416495851
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 17] 127.0.0.1 - POST
/signin/ since 1416495868
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 18] 127.0.0.1 - POST
/clientresp since 1416495866
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 19] 127.0.0.1 - GET
/getsources?fid=&extrarefs=Doktorigi%3A8 since 1416495868
Thu Nov 20 15:09:29 2014 - HARAKIRI !!! end of worker 8 status !!!
DAMN ! worker 8 (pid: 5046) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 8 (new pid: 10985)
monitor (pid=10985): Starting stack trace monitor.
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa3dd80
pid: 10985 (default app)

When the server is able to successfully restart the worker, the
message looks similar.  Here's our latest:

Fri Nov 21 18:36:12 2014 - *** HARAKIRI ON WORKER 5 (pid: 23549, try: 1) ***
HARAKIRI: -- wchan> futex_wait_queue_me
Fri Nov 21 18:36:12 2014 - HARAKIRI !!! worker 5 status !!!
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 0] 127.0.0.1 - GET /plot
since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 1] 127.0.0.1 - POST
/getuser/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 2] 127.0.0.1 - POST
/user_account_actions since 1416594370
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 3] 127.0.0.1 - GET /plot
since 1416594366
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 4] 127.0.0.1 - POST /pullf/
since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 5] 127.0.0.1 - POST
/clientresp since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 6] 127.0.0.1 - GET
/python/3d-plots-tutorial/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 7] 127.0.0.1 - POST
/getuser/ since 1416594370
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 8] 127.0.0.1 - POST
/getuser/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 9] 127.0.0.1 - POST
/getuser/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 10] 127.0.0.1 - POST
/getuser/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 11] 127.0.0.1 - POST
/svgtopdf/ since 1416594371
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 12] 127.0.0.1 - POST
/clientresp since 1416594366
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 13] 127.0.0.1 - GET
/quandl?code=WORLDBANK/UZB_SP_RUR_TOTL_ZS since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 14] 127.0.0.1 - GET
/~martin.2098/20/-line0-css-penthouse-line0-line0 since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 15] 127.0.0.1 - POST
/user_account_actions since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 16] 127.0.0.1 - GET /plot
since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 17] 127.0.0.1 - GET /plot
since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 18] 127.0.0.1 - POST
/clientresp since 1416594371
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 19] 127.0.0.1 - POST
/getnotifs/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI !!! end of worker 5 status !!!
DAMN ! worker 5 (pid: 23549) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 5 (new pid: 24129)
monitor (pid=24129): Starting stack trace monitor.
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xae8aa0
pid: 24129 (default app)

Configuration from --show-config:

;uWSGI instance configuration
[uwsgi]
show-config = true
emperor = /etc/streambed_uwsgi.ini
;end of configuration

Contents of /etc/streambed_uwsgi.ini:

[uwsgi]

uid = www-data
gid = www-data

chdir = /var/www/streambed/shelly
module = apache.wsgi
socket = /var/run/streambed.sock
chown-socket = www-data
logto = /var/log/uwsgi/streambed
pidfile = /var/run/streambed.pid

master = true
# Conventional SIGTERM behaviour - needed for runit:
die-on-term = true
# Clean up on exit:
vacuum = true

# 10 processes, 20 threads each:
processes = 10
threads = 20

buffer-size = 32768

# Load the app in each worker process, rather than in the master process:
lazy = true
# Maximum time to service a request (seconds):
harakiri = 300
harakiri-verbose = true
# Reload each process after this number of requests:
max-requests = 10000
# Save HTTP bodies larger than this to disk (bytes):
post-buffering = 1000000

# Stats socket
stats = /var/run/uwsgi/streambed.stats

Thanks for any hints or suggestions on either of these issues!

Jody McIntyre
Plotly Engineering
daedae11 | 19 Nov 10:38 2014

Question about --processes and --threads

Hi, I'm a new comer for uwsgi.

I'm confused about the two question a whole day:
1. I wonder about the difference between argument "--processes 4" and argument "--processes 2 --threads 2".
2. Why should we use nginx + uwsgi , since uwsgi support http and cluster?

help, please


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

Gmane