nitin chandra | 20 Oct 10:16 2014
Picon

Is there any issue with my configurations

Hi All,

below are the nginx-uwsgi.conf and project.ini files

q) Why does the new page not 'display' its content?

in the top URL field, insertDB.py script file name appears... but the
page content displayed is still of index.py page ..

===============================
nginx-uwsgi.conf
-----------------------
server {
  listen 81 default_server;
  server_name localhost;

  location / {
                root /home/nitin/project;
                index  index.py index.html index.htm;
  }

  location ~ \.py$ {
    include uwsgi_params;
    uwsgi_modifier1 9;
    uwsgi_pass 127.0.0.1:9090;
    uwsgi_param UWSGI_PYHOME /home/nitin/project;
    autoindex on;
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9090;
    fastcgi_index index.py;
(Continue reading)

Stephen Hamer | 20 Oct 05:29 2014
Picon

accepting1-once writefifo race with master-fifo in "The Zerg Dance"

Hi,
I've been experimenting with uWSGI's graceful reloading. My toy example is in <https://github.com/shamer/uwsgi_rolling_restart>.

I've followed the "The Zerg Dance" instructions at <http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html>. There seems to be a race between the hook-accepting1-once writefifo to the new.fifo and the master opening the master-fifo.

If I set the number of processes to spawn to a low number (experimentally I've found <4 to work on my machine) it works as expected. If I replace the "writefifo: new.fifo 1" with an "echo 1 > new.fifo" everything works as expected as well. With "echo" any number of processes works.

I'm using uWSGI version 2.0.7 on a 3.16.4 kernel. uWSGI was built with gcc 4.9.1. I'm running a python application. The python version is 3.4.2.

Is using "echo" in the accepting1-once hook the preferred way of doing this new.fifo -> running.fifo transition? Is there a way to get the "writefifo" method to work?

Thanks,
Stephen
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
nitin chandra | 15 Oct 16:33 2014
Picon

No action on form

Hi All,

I wrote a python script to load a web form. In my [wsgi] config i have given

[uwsgi]
http-socket    = :9090
plugin    = cgi
wsgi-file = /home/user/project/index.py
process   = 3
master = yes
thunder-lock = yes
enable-threads = yes
exit-on-reload = true
cgi = /home/nitin/finhealth
cgi-index = index.py
cgi-allowed-ext = .py
cgi-helper = .py=python

When I click on "Submit" button, Next page does not load.

Next Page shows If the data entered in the WebForm is correct, IF yes
insert into DB else cancel / Back.

Do I need to correct some thing in the uWSGI / Nginx config ?

Thanks

Nitin
ROMAHi4 | 14 Oct 16:37 2014
Picon

HARAKIRI: -- wchan> poll_schedule_timeout

Hello, uwsgi community.

We have used uwsgi 2.0.7 for a long time and everything was fine.
Today we have received following in logs.

Tue Oct 14 08:36:32 2014 - Respawned uWSGI worker 1 (new pid: 32683)
Tue Oct 14 08:36:32 2014 - mapped socket 0 (127.0.0.1:50031) to worker 1
Tue Oct 14 08:36:33 2014 - *** HARAKIRI ON WORKER 2 (pid: 32434) ***
Tue Oct 14 08:36:33 2014 - HARAKIRI: -- wchan> poll_schedule_timeout
Tue Oct 14 08:36:33 2014 - HARAKIRI: --- uWSGI worker 2 (pid: 32434) WAS managing request / since Tue Oct 14 08:36:33 2014 ---
{address space usage: 174055424 bytes/165MB} {rss usage: 48521216 bytes/

And it repeats all the time. Uwsgi just relaunches workers all the time...

hdd space - ok
ram amount - ok

Ubuntu 12.04
Django 1.6.6

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

uWSGI with PyPy

Dear uWSGI community,

I'm an experienced Python web developer but new to both uWSGI and PyPy. I'm interested in uWSGI and PyPy because a web application I'm building needs to serve a high volume of traffic and will use significant CPU per request.

I found the docs at http://uwsgi-docs.readthedocs.org/en/latest/PyPy.html but I'm having trouble sorting through all the available options. It sounds like I can use http://projects.unbit.it/downloads/pypy/libpypy-c-x86_64.so on an Ubuntu Trusty 64-bit server to avoid building/translating lbypypy-c myself, which would be preferable.

So how can I get from the libpypy-c-x86_64.so I downloaded to a new pypy virtualenv which uses that .so, into which I can (pip?) install uWSGI?

Thanks in advance for any help you can provide.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
nitin chandra | 10 Oct 10:14 2014
Picon

Dynamin REloading / Refesh

Hi All,

I have been searching the net to find a solution to "Refresh" the web
page and see the latest development.

Else I am left with "Restarting" the uWSGI server every time.

# services uwsgi restart

To see the latest changes to the web page.

Can some one please point to the link giving this solution ?

Or  Suggest how to tweak the configuration ?

Thank

Nitin
Roberto Bampi | 8 Oct 17:19 2014
Picon

uwsgi in docker

Hi all,
we are trying to use uwsgi to host a django application in a docker [1] container.
Docker's main way to configure packaged application is to pass environment variables to them.
So I configured my django application to read most of the settings from os.environ but it seems like uwsgi does not pass the environment variables it receives from the parent to the children.
Is there a way to enable this behavior in uwsgi?

Regards,
Roberto Bampi

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Tamer Higazi | 8 Oct 00:17 2014

Re: problems building php plugin

I got it solved!
inside plugins/php/uwsgiplugin.py

I set:

ld_run_path = None

to

ld_run_path = '/usr/local/php53-emb/lib'

and it worked!

Am 06.10.2014 um 22:56 schrieb Tamer Higazi:
> Hi people,
> I tried to build the php plugin on a different machine.
> Can somebody tell me how to build the plugin without problems ?!
> 
> I have built php as embedded version and installed it on:
> /usr/local/php53-emb
> 
> 
> 
> 
> Output:
> 
> tamer <at> tux /usr/local/src/uwsgi-2.0.7 $
> UWSGICONFIG_PHPPATH=/usr/local/php53-emb/bin/php-config python
> uwsgiconfig.py --plugin plugins/php
> using profile: buildconf/default.ini
> detected include path: ['/usr/include', '/usr/local/include']
> *** uWSGI building and linking plugin plugins/php ***
> [x86_64-pc-linux-gnu-gcc -pthread] ./php_plugin.so
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld:
> cannot find -lphp5
> collect2: Fehler: ld gab 1 als Ende-Status zurück
> *** unable to build php plugin ***
> 
> 
> 
> for any hints, thank you!
> 
> 
> Tamer
> 

_______________________________________________
uWSGI mailing list
uWSGI <at> lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
nitin chandra | 4 Oct 21:56 2014
Picon

Starting uwsgi: unable to load configuration from 4

Hello All,

I am getting above subject matter error while trying to start

# sudo service uwsgi start

I DO NOT have a uwsgi.conf in /etc/init
Is it required ? Also, I wont be using any frame works in development.

I HAVE a uwsgi executalbe in /etc/init.d

# uwsgi --ini Test.ini  -- WORKS
--------------------------------------------------------------------------
nitin <at> nitin:~/finhealth$ cat Test.ini
[uwsgi]
http-socket    = :9090
# plugin    = python
wsgi-file = /home/nitin/finhealth/test.py
process   = 3
master = yes
thunder-lock = yes
enable-threads = yes
exit-on-reload = true
-------------------------------------------------------------------------

Trying to solve this for past Month. PL HELP !!!

Pasting my /etc/init.d/uwsgi file below
============================================
#!/bin/sh

### BEGIN INIT INFO
# Provides:          uwsgi
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the uwsgi app server
# Description:       starts uwsgi app server using start-stop-daemon
### END INIT INFO

PATH=/opt/uwsgi:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
DAEMON=/usr/local/bin/uwsgi

OWNER=uwsgi

NAME=uwsgi
DESC=uwsgi

test -x $DAEMON || exit 0

# Include uwsgi defaults if available
if [ -f /etc/default/uwsgi ] ; then
        . /etc/default/uwsgi
fi

set -e

DAEMON_OPTS="-s 127.0.0.1:9090 -M 4 -t 30 -A 4 -p 4 -d
/var/log/uwsgi.log --pythonpath $PYTHONPATH --module $MODULE"

case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --chuid $OWNER:$OWNER --user $OWNER \
                --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --signal 3 --user $OWNER --quiet --retry 2 --stop \
                --exec $DAEMON
        echo "$NAME."
        ;;
  reload)
        killall -1 $DAEMON
        ;;
  force-reload)
        killall -15 $DAEMON
       ;;
  restart)
        echo -n "Restarting $DESC: "
        start-stop-daemon --signal 3 --user $OWNER --quiet --retry 2 --stop \
                --exec $DAEMON
        sleep 1
        start-stop-daemon --user $OWNER --start --quiet --chuid $OWNER:$OWNER \
               --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  status)
        killall -10 $DAEMON
        ;;
      *)
            N=/etc/init.d/$NAME
            echo "Usage: $N {start|stop|restart|reload|force-reload|status}" >&2
            exit 1
            ;;
    esac
    exit 0

====================================================
Steven Blatchford | 23 Sep 21:22 2014
Picon

nginx+uWSGI and imagemagick

I have a shell script run by some python code using imagemagick's convert to
resize images.  If I run the python code from the cli, it uses 4 cpu cores.  If
I run the script through a webpage via nginx+uwsgi it uses 1 core.  If I set
'cpu-affinity' to '2', convert uses two cores.  Any value higher than 2 results
in two cores being used.  Is uWSGI limiting the number of cores used?  nginx?

Operating system:   Arch Linux
CPU architecture:   x64
Webserver:          nginz
uWSGI version:      2.0.1

$ cat /etc/uwsgi/common.ini
[uwsgi]
print =  <at>  <at>  <at>  %n.ini loading  <at>  <at>  <at> 
strict = true
socket = /tmp/%(my_config_name).socket
chmod-socket = 666
chown-socket = http:http
plugins = python2
mount = /=wsgihandler:application
processes = 1
#harakiri = 60 
harakiri = 600 
post-buffering = 4096
cpu-affinity = 2
stats = /tmp/stats.socket
max-requests = 2000
limit-as = 512 
reload-on-as = 256
reload-on-rss = 192
no-orphans = true
enable-threads = true
threads = 4
Roberto De Ioris | 21 Sep 08:42 2014
Picon

Important api change for plugin developers


Hi all, as promised uWSGI 2.1 will not be limited anymore to 16bit request
size.

All of the protocols (except uwsgi/suwsgi/uwsgip obviously) can now manage
64bit request size. By default the buffer size is limited to 4k as always
(yeah, i know this is annoying for someone, but unfortunately moving to 8k
would result in an automatic double in memory usage for users of async
modes, so we need to think about it a little bit more).

This means that users of mercurial (that makes an heavy use of http
headers to carry blobs) can now use it with uWSGI simply setting
http/fastcgi/scgi/... protocols.

From the plugin developers point of view there are two major changes:

uwsgi.buffer_size is 64bit, and the old pointer has been mapped to
uwsgi.__buffer_size (to retain ABI compatibility).

wsgi_req->uh->pktsize has been renamed to wsgi_req->uh->_pktsize to avoid
errors, as the new way for checking the request size is wsgi_req->len

wsgi_req->uh->_pktsize is meaningful only for plugins directly dealing
with uwsgi protocol.

Take in account that even if uwsgi requests are limited to 16bit (by
protocol specs), internally you are free to extend it to 64bit, so you are
able to add request-vars via internal routing framework. So having a
buffer-size > 64k could be useful even for plain uwsgi mode.

To be more clear:

- you set buffer size to 100k
- you receive a 8000 bytes requests from nginx.
- via internal routing you add a variable FOO=x * 80000
- your internal request buffer is now 88000 bytes, and it is still valid
as it is lower than 100k

but:

- nginx sending a huge 80k request (that will overflow)
- albeit the buffer is 100k the uwsgi protocol can carry only 64k, so the
request will be detected as broken and the connection closed.

This commit is very invasive, thanks to Adriano Di Luzio (a new member of
the uWSGI team) we are improving our test suite, but i expect corner bugs
;) . Every report will be welcomed.

--

-- 
Roberto De Ioris
http://unbit.it

Gmane