Jimmy Gawain | 4 Mar 17:58 2015
Picon

Workers not respecting max-worker-lifetime

On the following Debian box:

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).

The relevant portion of my ini file is:

single-interpreter = true
lazy-apps = true
maxrequests = 200
reload-on-as = 256
max-worker-lifetime = 3600

At Wed Mar  4 13:57:54 UTC 2015, I took a look at the uwsgi processes that were running:

www-data 16852 16569  0 Mar03 ?        00:00:02 /usr/local/bin/uwsgi --ini redacted.ini
www-data 16987 16569  0 Mar03 ?        00:00:01 /usr/local/bin/uwsgi --ini redacted.ini
www-data 17053 16569  0 Mar03 ?        00:00:02 /usr/local/bin/uwsgi --ini redacted.ini
www-data 17226 16569  0 Mar03 ?        00:00:01 /usr/local/bin/uwsgi --ini redacted.ini
www-data 18557 16569  0 02:59 ?        00:00:01 /usr/local/bin/uwsgi --ini redacted.ini
www-data 19199 16569  0 04:33 ?        00:00:02 /usr/local/bin/uwsgi --ini redacted.ini
www-data 19443 16569  0 05:24 ?        00:00:01 /usr/local/bin/uwsgi --ini redacted.ini
www-data 20022 16569  0 07:05 ?        00:00:01 /usr/local/bin/uwsgi --ini redacted.ini
www-data 21240 16569  0 10:26 ?        00:00:08 /usr/local/bin/uwsgi --ini redacted.ini
www-data 21951 16569  0 13:15 ?        00:00:04 /usr/local/bin/uwsgi --ini redacted.ini

Processes 16852 16987 17053 17053 were no longer responding to the front end nginx server; it connects to them, hangs for some number of seconds, then returns a 404.

I would have expected those processes to have been killed hours ago as they are well outside the 3600 second configuration for max-worker-lifetime. Is there some reason why they are still hanging around?

tx

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Lucas Castro | 26 Feb 20:38 2015
Picon

uWSGI segfault

Hello, i'm getting segfault, can anyone help me to debug this?
idk if this is enough but if you need me to do anything else just tell me and i'll do it.

i also tried with 2.0.9 and 1.4 versions and i also get segfaults.

thanks!


;uWSGI instance configuration
[uwsgi]
ini = /etc/uwsgi/uwsgi.ini
paste = config:/var/sites/evolux/production.ini
socket = /tmp/uwsgi.sock
home = /usr/local/pythonenv/evolux/
workers = 4
pidfile = /var/run/evolux/uwsgi.pid
daemonize = /var/log/evolux/uwsgi.log
show-config = true
;end of configuration

*** Starting uWSGI 2.1 (64bit) on [Thu Feb 26 16:34:32 2015] ***
compiled with version: 4.4.5 on 26 February 2015 16:24:40
os: Linux-2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011
nodename: liga
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /
writing pidfile to /var/run/evolux/uwsgi.pid
detected binary path: /usr/local/pythonenv/evolux/bin/uwsgi
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.6.6 (r266:84292, Dec 26 2010, 22:48:11)  [GCC 4.4.5]
Set PythonHome to /usr/local/pythonenv/evolux/
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x11833c0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
your request buffer size is 4096 bytes
mapped 363960 bytes (355 KB) for 4 cores
*** Operational MODE: preforking ***
Loading paste environment: config:/var/sites/evolux/production.ini
!!! uWSGI process 32331 got Segmentation Fault !!!
*** backtrace of 32331 ***
/usr/bin/uwsgi(uwsgi_backtrace+0x29) [0x476ad9]
/usr/bin/uwsgi(uwsgi_segfault+0x21) [0x476c61]
/lib/libc.so.6(+0x32230) [0x7f2e96b0f230]
/usr/lib/libcrypto.so.1.0.0(EVP_PKEY_CTX_dup+0x20) [0x7f2e97b80f10]
/usr/lib/libcrypto.so.1.0.0(EVP_MD_CTX_copy_ex+0xbe) [0x7f2e97b7341e]
/usr/lib/libpython2.6.so.1.0(+0x1500ea) [0x7f2e971c60ea]
/usr/lib/libpython2.6.so.1.0(+0x1503a4) [0x7f2e971c63a4]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5180) [0x7f2e9716bf80]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f2e9716dcc0]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x32) [0x7f2e9716dd92]
/usr/lib/libpython2.6.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x7f2e9717f0d2]
/usr/lib/libpython2.6.so.1.0(+0x10b99e) [0x7f2e9718199e]
/usr/lib/libpython2.6.so.1.0(+0x10c7df) [0x7f2e971827df]
/usr/lib/libpython2.6.so.1.0(+0x10cab0) [0x7f2e97182ab0]
/usr/lib/libpython2.6.so.1.0(+0x10d0b0) [0x7f2e971830b0]
/usr/lib/libpython2.6.so.1.0(PyImport_ImportModuleLevel+0x44) [0x7f2e97183604]
/usr/lib/libpython2.6.so.1.0(+0xefbaf) [0x7f2e97165baf]
/usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f2e970c6103]
/usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x7f2e97166103]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2d98) [0x7f2e97169b98]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f2e9716dcc0]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x32) [0x7f2e9716dd92]
/usr/lib/libpython2.6.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x7f2e9717f0d2]
/usr/lib/libpython2.6.so.1.0(+0x10b99e) [0x7f2e9718199e]
/usr/lib/libpython2.6.so.1.0(+0x10c7df) [0x7f2e971827df]
/usr/lib/libpython2.6.so.1.0(+0x10ca6f) [0x7f2e97182a6f]
/usr/lib/libpython2.6.so.1.0(+0x10d0f0) [0x7f2e971830f0]
/usr/lib/libpython2.6.so.1.0(PyImport_ImportModuleLevel+0x44) [0x7f2e97183604]
/usr/lib/libpython2.6.so.1.0(+0xefbaf) [0x7f2e97165baf]
/usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f2e970c6103]
/usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x7f2e97166103]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2d98) [0x7f2e97169b98]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f2e9716dcc0]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x32) [0x7f2e9716dd92]
/usr/lib/libpython2.6.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x7f2e9717f0d2]
/usr/lib/libpython2.6.so.1.0(+0x10b99e) [0x7f2e9718199e]
/usr/lib/libpython2.6.so.1.0(+0x10c7df) [0x7f2e971827df]
/usr/lib/libpython2.6.so.1.0(+0x10ca6f) [0x7f2e97182a6f]
/usr/lib/libpython2.6.so.1.0(+0x10d0f0) [0x7f2e971830f0]
/usr/lib/libpython2.6.so.1.0(PyImport_ImportModuleLevel+0x44) [0x7f2e97183604]
/usr/lib/libpython2.6.so.1.0(+0xefbaf) [0x7f2e97165baf]
/usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f2e970c6103]
/usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x7f2e97166103]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2d98) [0x7f2e97169b98]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f2e9716dcc0]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x32) [0x7f2e9716dd92]
/usr/lib/libpython2.6.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x7f2e9717f0d2]
/usr/lib/libpython2.6.so.1.0(+0x10b99e) [0x7f2e9718199e]
/usr/lib/libpython2.6.so.1.0(+0x10c22d) [0x7f2e9718222d]
/usr/lib/libpython2.6.so.1.0(+0x10c7df) [0x7f2e971827df]
/usr/lib/libpython2.6.so.1.0(+0x10ca6f) [0x7f2e97182a6f]
/usr/lib/libpython2.6.so.1.0(+0x10d0f0) [0x7f2e971830f0]
/usr/lib/libpython2.6.so.1.0(PyImport_ImportModuleLevel+0x44) [0x7f2e97183604]
/usr/lib/libpython2.6.so.1.0(+0xefbaf) [0x7f2e97165baf]
/usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53) [0x7f2e970c6103]
/usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x7f2e97166103]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x2d98) [0x7f2e97169b98]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920) [0x7f2e9716dcc0]
/usr/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x32) [0x7f2e9716dd92]
/usr/lib/libpython2.6.so.1.0(PyImport_ExecCodeModuleEx+0xc2) [0x7f2e9717f0d2]
/usr/lib/libpython2.6.so.1.0(+0x10b99e) [0x7f2e9718199e]
/usr/lib/libpython2.6.so.1.0(+0x10c7df) [0x7f2e971827df]
/usr/lib/libpython2.6.so.1.0(+0x10ca6f) [0x7f2e97182a6f]
/usr/lib/libpython2.6.so.1.0(+0x10d0f0) [0x7f2e971830f0]
*** end of backtrace ***

--
Atenciosamente,

Lucas Marques de Castro
Gerente de Operações
 

EVOLUX - Call Center ACD & Analytics

Rua Coronel Luiz Júlio, 2018, 59056-240 | Natal / RN | Brasil
Tel.: (84) 4008-9060 (Natal) | 4003-3833 (Demais localidades) 

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Poh Yee Hui | 19 Feb 23:04 2015
Picon

requests not handled

Hi,

I have a problem with uWSGI not taking in any request sometimes. Everything looks normal, except that no requests are handled (according to the log) and I get a timeout on my browser after a very long time.
The situation is like this, when I started uWSGI (with emperor), it seems running normally, with workers spawned. However, requests just don't get handled. If I do restart uWSGI, there might be a chance which everything looks the same, and the requests are handled. I have no idea what is going on so I hope that I can get some help over here.

I have provided the uWSGI log and the config file below.
Thanks.

uWSGI log:
WSGI app 0 (mountpoint='') ready in 56 seconds on interpreter 0x14a61a0 pid: 1398 (default app)
spawned uWSGI master process (pid: 1398)
spawned uWSGI worker 1 (pid: 1437, cores: 4)
spawned uWSGI worker 2 (pid: 1438, cores: 4)
spawned uWSGI worker 3 (pid: 1439, cores: 4)
spawned uWSGI worker 4 (pid: 1440, cores: 4)
*** Stats server enabled on 127.0.0.1:9191 fd: 21 ***

uWSGI configuration file:
[uwsgi]
socket = /var/run/uwsgi/myserver.sock
;http = :8080
stats = 127.0.0.1:9191
pidfile = /var/run/uwsgi/myserver.pid
daemonize = /var/log/uwsgi/myserver.log
log-slow = true

master = true

chdir = /srv/MyCompany/myserver
wsgi-file = /srv/MyCompany/myserver/main.py

#processes = 8
processes = 4
enable-threads = true
threads = 4 ; 4
#offload-threads = 1 ; 1
offload-threads = 0
single-interpreter = true

harakiri = 30
limit-post = 65536
post-buffering = 8192

uid = root
;uid = mycompany
gid = i2c

#queue = 10
queue = 10
#queue-blocksize = 500000
queue-blocksize = 10000
reload-os-env = true

locks = 2



--


Regards,
Poh Yee Hui

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Jens Tröger | 18 Feb 06:37 2015
Picon

uwsgi returns empty responses

Hi,

I'm trying out uwsgi to see if it solves my problem of running different
webapps and Python versions through a single Apache instance.  It
seems to, somehow.  Requests make it through Apache and arrive at my
uwsgi server.  The server is set up like so:

[uwsgi]
master = true
socket = localhost:3101
plugins = python34
virtualenv = /path/to/venv
wsgi-file = /path/to/venv/test-wsgi.py
processes = 1
threads = 2

and my test script is simple:

import sys
def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return "Running " + str(sys.version_info)

Everything seems to work fine, except that the responses from the server
are empty. There is output from uwsgi though:

[pid: 32275|app: 0|req: 1/1] 73.193.3.79 () {58 vars in 1241 bytes} [Wed Feb 18 03:29:53 2015] GET / =>
generated 0 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 45 bytes (83 switches on core 0)
...

What's missing here?
Thanks, Jens

--

-- 
Jens Tröger
http://savage.light-speed.de/
James | 17 Feb 21:39 2015

Emperor for a single application

Hi,

I was just wondering, is there a benefit for using emperor when I am only ever going to run a single application? I had in my head that it might be good in terms of restarting the application when it crashes but this might be covered by running uwsgi with an init.d script.

Any feedback would be appreciated.

James
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
James | 13 Feb 23:12 2015

Autostart UWSGI on debian 7

Hi,

Can anyone point me to a init.d script I can use for debian 7. I can find lots of examples of init scripts for uwsgi, but they vary significantly. 

https://github.com/jbq/uwsgi/blob/master/debian/uwsgi.init.d

Is there some sort of official example, or could anyone give me a tip on where to find the most complete example?

James
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Ben Roberts | 13 Feb 20:37 2015

Premature Harakiris with multi-threaded uWSGI server

I've been recently testing out 2:1 concurrency (2 threads per process) instead of just 1:1, in order to get more out of Heroku dynos' limited memory.  

When I switch threads to 2 in production, I start to see a bunch of premature Harakiri's.  I have the `harakiri` setting to 25 seconds, but i see these much sooner, quite frequently and randomly, mostly for POST requests on a few select views. 

The following log snippet is illustrative of what is happening:


Feb 11 11:08:04 stockton app/web.3: Wed Feb 11 19:08:04 2015 - *** HARAKIRI ON WORKER 5 (pid: 215, try: 1) *** 
Feb 11 11:08:04 stockton app/web.3: HARAKIRI: -- syscall> 7 0x7fffb0804570 0x1 0xfa0 0xc65f337e4f7fbfe7 0x3 0x38a71004160bee26 0x7fffb0804540 0x7f2fa9e89cc3 
Feb 11 11:08:04 stockton app/web.3: HARAKIRI: -- wchan> poll_schedule_timeout 
Feb 11 11:08:04 stockton app/web.3: Wed Feb 11 19:08:04 2015 - HARAKIRI !!! worker 5 status !!! 
Feb 11 11:08:04 stockton app/web.3: Wed Feb 11 19:08:04 2015 - HARAKIRI [core 0] 10.68.129.226 - POST /admin/menus/food/256195/ since 1423681683 
Feb 11 11:08:04 stockton app/web.3: Wed Feb 11 19:08:04 2015 - HARAKIRI !!! end of worker 5 status !!!
Feb 11 11:08:04 stockton heroku/router: at=error code=H13 desc="Connection closed without response" method=POST path="/admin/menus/food/256195/" host=something.com request_id=111d5c11-fa66-452a-af95-4e76f4405739 fwd="0.0.246.97" dyno=web.3 connect=3ms service=1251ms status=503 bytes=0 
Feb 11 11:22:19 stockton app/web.1: Wed Feb 11 19:22:19 2015 - *** HARAKIRI ON WORKER 3 (pid: 158, try: 1) *** 
Feb 11 11:22:19 stockton app/web.1: HARAKIRI: -- syscall> running 
Feb 11 11:22:19 stockton app/web.1: HARAKIRI: -- wchan> 0 
Feb 11 11:22:19 stockton app/web.1: Wed Feb 11 19:22:19 2015 - HARAKIRI !!! worker 3 status !!! 
Feb 11 11:22:19 stockton app/web.1: Wed Feb 11 19:22:19 2015 - HARAKIRI [core 0] 10.4.105.38 - POST /admin/menus/menuweek/17446/ since 1423682539 
Feb 11 11:22:19 stockton app/web.1: Wed Feb 11 19:22:19 2015 - HARAKIRI !!! end of worker 3 status !!! 
Feb 11 11:22:19 stockton heroku/router: at=error code=H13 desc="Connection closed without response" method=POST path="/admin/menus/menuweek/17446/" host=something.com request_id=bd50bd40-b0a2-4c91-a596-50d0beb552d0 fwd="0.0.68.34" dyno=web.1 connect=1ms service=225ms status=503 bytes=0 


As you can see from the heroku/router lines, these requests are both cut off way below the 25 second harakiri threshold.

Here is my uwsgi.ini file:

[uwsgi]

http-socket = :$(PORT)
master = true
enable-threads = true
single-interpreter = true
die-on-term = true
harakiri = 25
harakiri-verbose
reload-mercy = 8
max-requests = 2000
post-buffering = 4096
thunder-lock = true
processes = 6
threads = 2
module = app.wsgi


As soon as I set threads back to 1 per process, I no longer see this issue.  Any ideas what might be causing this behavior? 

uWSGI Version is 2.0.9
 

Thanks

Ben Roberts

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

async wait_fd_read - yield vs suspend

The "yield" keyword has always been a little confusing to me (and many others).  I know how it works inside a generator function, but I'm a little unsure when it comes to the uwsgi async functionality.  Is there a difference between using yield and uwsgi.suspend()?

In the uwsgi docs I found:
    uwsgi.wait_fd_read(fd0)
    uwsgi.wait_fd_read(fd1)
    uwsgi.wait_fd_read(fd2)
    yield ""  # yield the app, let uWSGI do its magic

If I'm in the middle of a generator, though, what exactly does the `yield` do?  Does it yield a value to the caller or does it pass control back to the event engine or both?

I'm wondering if I should be calling uwsgi.suspend() in this case, but I'm not sure if that does the same sort of thing or not.

I'm using async=100 with ugreen=true in my configuration.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
James | 13 Feb 12:26 2015

Fwd: UWSGI starting in foreground

Hi all,

This is my UWSGI config:

[uwsgi] uid = $APPUSER gid = $APPGROUP socket = $SOCK processes = 4 chdir = $APPDIR virtualenv = $APPVENV pythonpath = $APPVENV/bin/python module = run callable = app emperor-pidfile = $APPDIR/emperor.pid daemonize = /var/log/emperor.log

When emperor runs it does create the emperor log file but it is running in the foreground and not in the background as a daemon.

What might be causing this?

James


_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Radosław Trojanowski | 12 Feb 14:06 2015
Picon

Pyramid + uWSGI + Apache - DAMN ! worker 1 (pid: 13) died, killed by signal 11 :( trying respawn ...

Hello,

I have problem with deploying Pyramid 1.5.2 application using uWSGI.

My setup:
Python 2.7.5
virtualenv
Apache
Linux
uWSGI 2.0.9 64bit

My Pyramid application works on virtualenv located at 
/www/virtual/t/trojanowski/piekarnia_wsgi.

Python in virtualenv is there:
/www/virtual/t/trojanowski/piekarnia_wsgi/bin/python

uWSGI process is fired with options:

home=/www/virtual/t/trojanowski/piekarnia_wsgi
wsgi-file=/www/virtual/t/trojanowski/piekarnia_wsgi/piekarnia.wsgi

WSGI file is following:

import os
import sys
print os.path.dirname(sys.executable)
print 'trying import pyramid...'
venv = '/www/virtual/t/trojanowski/piekarnia_wsgi/bin/activate_this.py'
print venv
execfile(venv, dict(__file__=venv))
from pyramid.paster import get_app, setup_logging
print str(get_app)
ini_path = '/www/virtual/t/trojanowski/piekarnia_wsgi/src/development.ini'
print str(ini_path)
setup_logging(ini_path)
application = get_app(ini_path, 'main')
print application

When in webbrowser I am invoking URL on traces see:

Thu Feb 12 13:59:13 2015 - *** Starting uWSGI 2.0.9 (64bit) on [Thu Feb 12 13:59:13 2015] ***
Thu Feb 12 13:59:13 2015 - compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-11) on 09 February 2015 11:38:24
Thu Feb 12 13:59:13 2015 - os: Linux-2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015
Thu Feb 12 13:59:13 2015 - nodename: www3
Thu Feb 12 13:59:13 2015 - machine: x86_64
Thu Feb 12 13:59:13 2015 - clock source: unix
Thu Feb 12 13:59:13 2015 - pcre jit disabled
Thu Feb 12 13:59:13 2015 - detected number of CPU cores: 8
Thu Feb 12 13:59:13 2015 - current working directory: /etc/uwsgi/vassals
Thu Feb 12 13:59:13 2015 - detected binary path: /usr/bin/uwsgi
Thu Feb 12 13:59:13 2015 - uWSGI running as root, you can use --uid/--gid/--chroot options
Thu Feb 12 13:59:13 2015 - chroot() to /chr
Thu Feb 12 13:59:13 2015 - running "mount -t proc none /proc" (as root)...
Thu Feb 12 13:59:13 2015 - setgid() to 2081
Thu Feb 12 13:59:13 2015 - setuid() to 6054
Thu Feb 12 13:59:13 2015 - chdir() to /www/virtual/t/trojanowski
Thu Feb 12 13:59:13 2015 - your processes number limit is 10
Thu Feb 12 13:59:13 2015 - your process address space limit is 536870912 bytes (512 MB)
Thu Feb 12 13:59:13 2015 - your memory page size is 4096 bytes
Thu Feb 12 13:59:13 2015 - detected max file descriptor number: 1024
Thu Feb 12 13:59:13 2015 - lock engine: pthread robust mutexes
Thu Feb 12 13:59:13 2015 - thunder lock: disabled (you can enable it with --thunder-lock)
Thu Feb 12 13:59:13 2015 - uwsgi socket 0 inherited INET address 127.0.0.1:5200 fd 0
Thu Feb 12 13:59:13 2015 - Python version: 2.7.5 (default, Dec 3 2013, 08:35:16) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]
Thu Feb 12 13:59:13 2015 - Set PythonHome to /www/virtual/t/trojanowski/piekarnia_wsgi
Thu Feb 12 13:59:13 2015 - Python main interpreter initialized at 0x208fa50
Thu Feb 12 13:59:13 2015 - python threads support enabled
Thu Feb 12 13:59:13 2015 - your server socket listen backlog is limited to 100 connections
Thu Feb 12 13:59:13 2015 - your mercy for graceful operations on workers is 60 seconds
Thu Feb 12 13:59:13 2015 - mapped 518400 bytes (506 KB) for 16 cores
Thu Feb 12 13:59:13 2015 - *** Operational MODE: preforking+threaded ***
Thu Feb 12 13:59:13 2015 - *** uWSGI is running in multiple interpreter mode ***
Thu Feb 12 13:59:13 2015 - spawned uWSGI master process (pid: 1)
Thu Feb 12 13:59:13 2015 - spawned uWSGI worker 1 (pid: 3, cores: 4)
/usr/bin
trying import pyramid...
/www/virtual/t/trojanowski/piekarnia_wsgi/bin/activate_this.py
/www/virtual/t/trojanowski/piekarnia_wsgi/src/development.ini
Thu Feb 12 13:59:21 2015 - WSGI app 0 (mountpoint='') ready in 8 seconds on interpreter 0x208fa50 pid: 3 (default app)
Thu Feb 12 13:59:22 2015 - DAMN ! worker 1 (pid: 3) died, killed by signal 11 :( trying respawn ...
Thu Feb 12 13:59:22 2015 - Respawned uWSGI worker 1 (new pid: 13)
/usr/bin
trying import pyramid...
/www/virtual/t/trojanowski/piekarnia_wsgi/bin/activate_this.py
/www/virtual/t/trojanowski/piekarnia_wsgi/src/development.ini
Thu Feb 12 13:59:30 2015 - WSGI app 0 (mountpoint='') ready in 8 seconds on interpreter 0x208fa50 pid: 13 (default app)
Thu Feb 12 13:59:31 2015 - DAMN ! worker 1 (pid: 13) died, killed by signal 11 :( trying respawn ...
Thu Feb 12 13:59:31 2015 - Respawned uWSGI worker 1 (new pid: 23)
/usr/bin
trying import pyramid...
/www/virtual/t/trojanowski/piekarnia_wsgi/bin/activate_this.py
/www/virtual/t/trojanowski/piekarnia_wsgi/src/development.ini


Content of development.ini is following:

/www/virtual/t/trojanowski/piekarnia_wsgi/src/development.ini

###
# app configuration
###

[app:main]
use = egg:bread

pyramid.reload_templates = true
pyramid.reload_assets = true
pyramid.debug_authorization = false
pyramid.debug_notfound = false
pyramid.debug_routematch = false
pyramid.default_locale_name = pl
pyramid.prevent_http_cache = true
pyramid.reload_all = true

available_languages = de en es pl pt
bread.secret_key = 

pyramid.includes =
    pyramid_debugtoolbar
    pyramid_tm
    pyramid_beaker
    pyramid_webassets
    pyramid_mako


#SQLAlchemy configuration
sqlalchemy.url = 
sqlalchemy.pool_size = 5
sqlalchemy.max_overflow = 1
sqlalchemy.pool_recycle = 3600
sqlalchemy.pool_timeout = 30
sqlalchemy.echo = false
database.schema = shop

#Beaker Cache configuration
cache.regions = 1s, 1m, 5m, 15m, 1h
cache.type = memory
cache.1s.expire = 1
cache.1m.expire = 60
cache.5m.expire = 300
cache.15m.expire = 900
cache.1h.expire = 3600


#Beaker Sessions configuration
session.type = file
session.data_dir = %(here)s/data/sessions/data
session.lock_dir = %(here)s/data/sessions/lock
session.key = 
session.secret = 
session.cookie_on_exception = true


#Webassets configuration
webassets.base_dir = bread:static/
webassets.base_url = /static
webassets.debug = True
webassets.updater = timestamp
webassets.static_view = True
webassets.jst_compiler = Handlebars.compile
#webassets.cache = True
#webassets.cache_max_age = 3600


# By default, the toolbar only appears for clients from IP addresses
# '127.0.0.1' and '::1'.
# debugtoolbar.hosts = 127.0.0.1 ::1

###
# wsgi server configuration
###

[server:main]
use = egg:waitress#main
host = 0.0.0.0
port = 6543

###
# logging configuration
###

###
# logging configuration
###

[loggers]
keys =  waitress, root, bread, sqlalchemy, performance, importer
[handlers]
keys = waitress, console, sqlalchemy, rotatelog, performance, importer

[formatters]
keys = generic, rotatelog, performance, importer

[logger_root]
level = INFO
handlers = console, rotatelog

[logger_bread]
level = DEBUG
handlers = rotatelog
qualname = bread

[logger_waitress]
level = DEBUG
handlers = waitress
qualname = waitress

[logger_performance]
level = INFO
handlers = performance, rotatelog
qualname = performance

[logger_importer]
level = INFO
handlers = importer, rotatelog
qualname = importer

[logger_sqlalchemy]
level = WARN
handlers = sqlalchemy, rotatelog
qualname = sqlalchemy.engine
# "level = INFO" logs SQL queries.
# "level = DEBUG" logs SQL queries and results.
# "level = WARN" logs neither.  (Recommended for production systems.)

[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic


[handler_waitress]
class: handlers.TimedRotatingFileHandler
args: (r'%(here)s/traces/waitress.log', 'midnight', 7, 14, 'utf-8', False, True)
level: DEBUG
formatter: rotatelog

[handler_rotatelog]
class: handlers.TimedRotatingFileHandler
args: (r'%(here)s/traces/trace.log', 'midnight', 7, 14, 'utf-8', False, True)
level: DEBUG
formatter: rotatelog

[handler_performance]
class: handlers.TimedRotatingFileHandler
args: (r'%(here)s/traces/performance.log', 'midnight', 7, 14, 'utf-8', False, True)
level: INFO
formatter: performance

[handler_importer]
class: handlers.TimedRotatingFileHandler
args: (r'%(here)s/traces/importer.log', 'midnight', 7, 14, 'utf-8', False, True)
level: INFO
formatter: importer

[handler_sqlalchemy]
class: handlers.TimedRotatingFileHandler
args: (r'%(here)s/traces/sqlalchemy.log', 'midnight', 7, 14, 'utf-8', False, True)
level: INFO
formatter: performance

[formatter_generic]
#format = %(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s
format = %(asctime)s %(levelname)-5.5s [%(name)s] %(message)s
datefmt=%m/%d %H:%M:%S

[formatter_exc]
format = %(asctime)s %(message)s

[formatter_rotatelog]
format: %(asctime)s %(levelname)s: %(message)s <file: %(filename)s, line: %(lineno)d>
datefmt: %d-%m-%Y, %H:%M:%S

[formatter_performance]
format = %(asctime)s,%(msecs)03d %(message)s
datefmt = %H:%M:%S

[formatter_importer]
format: %(asctime)s,%(msecs)03d %(levelname)s: %(message)s
datefmt: %d-%m-%Y, %H:%M:%S



Guys, do you have any idea why I am getting:
Thu Feb 12 13:59:31 2015 - DAMN ! worker 1 (pid: 13) died, killed by signal 11 :( trying respawn ...



Regards,
Radosław Trojanowski
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Brian Nuszkowski | 11 Feb 17:23 2015

uWSGI Stats Server with multiple master processes

Hello!

I am attempting to use the stats server feature, but I believe it is connecting to and reporting on a master process that isn't handling a bulk of the application work. I suspect it is reporting statics for the master process that is responsible for maintaining the --touch-logreopen functionality. Is there a way to specify which master pid to use? Or specify all of them?

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

Gmane