Il 01/01/2013 21:06 Arkaitz Mugica Islas ha scritto:
First of all, I would like to thank you for your FAST answer. As you
asked me here you have console's output:
$ uwsgi -x uwsgi-arkaitz.xml
[uWSGI] parsing config file uwsgi-arkaitz.xml
*** Starting uWSGI 1.4.4 (64bit) on [Tue Jan 1 20:47:11 2013] ***
compiled with version: 4.2.1 Compatible Apple Clang 4.1
((tags/Apple/clang-421.11.66)) on 31 December 2012 10:16:25
os: Darwin-12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52
PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64
nodename: macbook.local
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory:
/Users/arkaitz/Documents/workspace/foo/bar/bar
detected binary path: /Users/arkaitz/Documents/workspace/foo/bin
your processes number limit is 709
your memory page size is 4096 bytes
detected max file descriptor number: 256
lock engine: OSX spinlocks
uWSGI http bound on :8888 fd 3
uwsgi socket 0 bound to TCP address 127.0.0.1:32321 fd 6
Python version: 2.7.3 (default, Nov 17 2012, 19:54:34) [GCC 4.2.1
Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))]
Set PythonHome to /Users/arkaitz/Documents/workspace/foo
Python main interpreter initialized at 0x7f8592c08df0
python threads support enabled
your server socket listen backlog is limited to 100 connections
mapped 483456 bytes (472 KB) for 5 cores
*** Operational MODE: preforking ***
added /Users/arkaitz/Documents/workspace/foo/bar/bar/ to pythonpath.
WSGI app 0 (mountpoint='') ready in 5 seconds on interpreter
0x7f8592c08df0 pid: 2459 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 2459)
spawned uWSGI worker 1 (pid: 2462, cores: 1)
spawned uWSGI worker 2 (pid: 2463, cores: 1)
spawned uWSGI worker 3 (pid: 2464, cores: 1)
spawned uWSGI worker 4 (pid: 2465, cores: 1)
spawned uWSGI worker 5 (pid: 2466, cores: 1)
spawned uWSGI http 1 (pid: 2467)
When calling http://localhost:8888/ [4] nothing happens: the output
shown above doesn't change. When I was asked to allow connections to
uwsgi I answered 'yes'... Really strange, isn't it?
Remove
<socket>127.0.0.1:32321</socket>
or (better solution for me) if you want to maintain control over the
socket, add
<http-to>127.0.0.1:32321</http-to>
I suppose you were using a 1.0/pre-1.0 uWSGI release, where the first
socket was automatically choosen if no http destination was set.
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi