On Thursday, August 31, 2017 at 3:05:56 PM UTC-7, Massimo Di Pierro wrote: > > Can you tell us more about your setup? > >
AWS Linux, Python=2.7.12, web2py-shake-the-box: webp2y (2.14.6) + Rocket + Sqlite. Since this is still evolving into production, and usually doesn't involve a lot of maintenance, I'm still hand-starting from the command line (-i 0.0.0.0 -p 443 -c ...pem -k ....pem ), doing the password (I know, -a exists), and after a few seconds hitting ^z and then bg. Similar for port 80, which should return a 302, and then 2 -K invocations for scheduler stuff (I have 2 apps). I had a more recent failure-to-respond where there didn't seem to be anything in /var/log/messages, or any error in logs/web2py.log. The 443 process was still running (in some sense), so I killed it and did a fresh one, and things were back to normal. (This is the same system that isn't fully happy with uploading large files from a Windows inet client ... but that doesn't go comatose; it eventually times out and has a stack trace in logs/web2py.log; the uploaded file is properly saved at that point. I think it responds to other requests between the client thinking it's done and the timeout appears.) /dps On Monday, 28 August 2017 13:54:05 UTC-5, Dave S wrote: >> >> I came in to a message from UptimeRobot that my server was down (4:20 am >> mytime). So I check the logs ... >> >> The httpserver.log file ends at 4:02, with the last successful >> UptimeRobot check. The logs/web2py.log has 3 entries beyond that, at 4:05 >> Rocket is throwing an exception because self.sslobj.do_handshake() got >> "Connection reset by peer". Unfortunately, the traceback report doesn't >> indicate who the peer is .... is this something left over from the UR >> check, or a different client trying to access the service? >> >> ps -ef indicated that all my python processes were still running, but my >> browser timed out looking for the index page. I killed all the processes, >> restarted everything, and server is now responding normally to me and to >> UptimeRobot. Even though I'm preparing to switch to nginx, I'd like to >> better understand the Rocket "crash". >> >> The process had been started from the command line, and put in the >> background (and the parent shell eventually quitted). As an orphan >> process, no console messages are on the screen, and there is no more detail >> in the logs than the 3 tracebacks (all the same). The top level is >> rocket.py, line 590 (2.14.6), in listen(), which calls self.wrap_socket(), >> etc. Is there any place besides the log to look for artifacts that would >> give me more information? Oh, /var/log/messages has a "Possible SYN >> flooding pn port 443" entry at 4:05. >> >> Thanks for any pointers. >> >> Dave >> /dps >> >> >> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
