I'm connecting to MongoLabs on port 27157 Is that it?
Francisco Costa http://franciscocosta.com On Tue, Oct 18, 2011 at 18:53, Francisco Costa <[email protected]>wrote: > 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
