> I'm connecting to MongoLabs on port 27157 > > Is that it? > Yes :)
Good job, you have made a perfect debug at the first shot :) > > 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 > -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
