So I run this *ls -l /proc/2534/fd* total 0 lr-x------ 1 www-data www-data 64 2011-10-18 18:47 0 -> /dev/null lrwx------ 1 www-data www-data 64 2011-10-18 18:47 1 -> /var/log/uwsgi.log lr-x------ 1 www-data www-data 64 2011-10-18 18:47 10 -> /dev/urandom lrwx------ 1 www-data www-data 64 2011-10-18 18:47 12 -> anon_inode:[eventpoll] lrwx------ 1 www-data www-data 64 2011-10-18 18:47 13 -> socket:[6071] lrwx------ 1 www-data www-data 64 2011-10-18 18:47 2 -> /var/log/uwsgi.log lrwx------ 1 www-data www-data 64 2011-10-18 18:47 3 -> /dev/null lrwx------ 1 www-data www-data 64 2011-10-18 18:47 4 -> socket:[7847] lrwx------ 1 www-data www-data 64 2011-10-18 18:47 5 -> anon_inode:[eventpoll] lrwx------ 1 www-data www-data 64 2011-10-18 18:47 6 -> socket:[7916] lrwx------ 1 www-data www-data 64 2011-10-18 18:48 7 -> socket:[9746] lrwx------ 1 www-data www-data 64 2011-10-18 18:48 8 -> socket:[9751] lrwx------ 1 www-data www-data 64 2011-10-18 18:48 9 -> socket:[9754]
I then checked for socket number 9: *lsof | grep 9754* uwsgi 2534 www-data 9u IPv4 9754 0t0 TCP mercury.tymr.com:40323->ec2-50-19-86-168.compute-1.amazonaws.com:27157(ESTABLISHED) just before of having the following error: *** HARAKIRI ON WORKER 3 (pid: 2534) *** HARAKIRI: -- syscall> 45 0x9 0x17890fc 0x10 0x0 0x0 0x0 0x7fffff313a40 0x7f7b4bd2f4b2 HARAKIRI: -- wchan> sk_wait_data HARAKIRI: --- uWSGI worker 3 (pid: 2534) WAS managing request /default/user/login?_next=%2Fplace%2Fcategory%2F1%2Friver since Tue Oct 18 18:47:59 2011 --- DAMN ! worker 3 (pid: 2534) died :( trying respawn ... I'm run in a Linode Ubuntu machine, but i don't know what happen at port 40323, or even if the error is port related.. Francisco Costa http://franciscocosta.com On Tue, Oct 18, 2011 at 17:57, Roberto De Ioris <[email protected]> wrote: > > > Hi, i was unable to test sooner because the site went up when you answer. > > Now that it went down I add --harakiri-verbose and i fot the following > > > > *** Starting uWSGI 0.9.9.2 (64bit) on [Tue Oct 18 17:46:42 2011] *** > > compiled with version: 4.5.2 on 27 September 2011 19:38:54 > > detected binary path: /usr/local/bin/uwsgi > > your memory page size is 4096 bytes > > *** WARNING: you have enabled harakiri without post buffering. Slow > > upload > > could be rejected on post-unbuffered webservers *** > > shared area mapped at 0x7f9670600000, you can access it with > > uwsgi.sharedarea* functions. > > uwsgi socket 0 bound to TCP address 127.0.0.1:9001 fd 4 > > Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:37:12) [GCC 4.5.2] > > Python main interpreter initialized at 0x24142d0 > > your server socket listen backlog is limited to 100 connections > > *** Operational MODE: preforking *** > > added /opt/web2py/ to pythonpath. > > WSGI application 0 (mountpoint=) ready on interpreter 0x24142d0 pid: > 16069 > > (default app) > > *** uWSGI is running in multiple interpreter mode *** > > spawned uWSGI master process (pid: 16069) > > spawned uWSGI worker 1 (pid: 16076, cores: 1) > > spawned uWSGI worker 2 (pid: 16077, cores: 1) > > spawned uWSGI worker 3 (pid: 16078, cores: 1) > > spawned uWSGI worker 4 (pid: 16079, cores: 1) > > *** HARAKIRI ON WORKER 2 (pid: 16077) *** > > HARAKIRI: -- syscall> 45 0xb 0x2ecd524 0x10 0x0 0x0 0x0 0x7fffb4588c20 > > 0x7f9670202092 > > HARAKIRI: -- wchan> sk_wait_data > > HARAKIRI: --- uWSGI worker 2 (pid: 16077) WAS managing request / since > Tue > > Oct 18 17:46:45 2011 --- > > DAMN ! worker 2 (pid: 16077) died :( trying respawn ... > > Respawned uWSGI worker 2 (new pid: 16080) > > > > > > You can interpret in this way: > > worker 2 blocked for more than 30 seconds waiting for network data > (sk_wait_data). > > syscall 45 on x86_64 is __NR_recvfrom, with its first argument (the file > descriptor/socket) being the 11 (0xb). > > So: the worker is waiting for data from socket 11, but those data did not > come. > > Who is socket 11 ? it could be a database connection (check your db logs) > or an external server connection. For sure it cannot be the uwsgi socket > (being it very low in number, normally the 3). You can get the list of > descriptors with > > ls -l /proc/<pid>/fd > > check for 11, you should get a number for the socket, then you can do > > lsof | grep <number> > > But i suppose you know to who your app connect to :) > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
