Those guys from MongoLab are failing a lot lately..
I will contact them.
Thaks very much for the support ;)

Francisco Costa
http://franciscocosta.com



On Tue, Oct 18, 2011 at 19:01, Roberto De Ioris <[email protected]> wrote:

>
> > 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
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to