On Friday, September 1, 2017 at 4:07:33 PM UTC-7, Dave S wrote: > > > > 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. > >> >> I did an experiment with one of these hangs, opening an ssh session to get a command line (the usual way I deal with admin'ing this headless system), and then trying to curl to / (that defaults to myapp/default/index, of course) -- the connection seems to have timed out.
[ec2-user@ip-172-31-16-18 web2py-2.14.6]$ curl -v --GET https://127.0.0.1/ * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5961 (PR_CONNECT_RESET_ERROR) * TCP connection reset by peer * Curl_http_done: called premature == 1 * Closing connection 0 curl: (35) TCP connection reset by peer [ec2-user@ip-172-31-16-18 web2py-2.14.6]$ [ec2-user@ip-172-31-16-18 web2py-2.14.6]$ date Thu Sep 14 04:39:03 UTC 2017 The date is helpful when looking at the log (httpserver.log). 63.143.42.248, 2017-09-13 22:19:39, HEAD, /, HTTP/1.1, 200, 0.022028 63.143.42.248, 2017-09-13 22:34:39, HEAD, /, HTTP/1.1, 200, 0.021980 63.143.42.248, 2017-09-13 22:49:39, HEAD, /, HTTP/1.1, 200, 0.022100 63.143.42.248, 2017-09-14 00:16:36, GET, /, HTTP/1.1, 200, 0.097000 63.143.42.248, 2017-09-14 00:19:15, HEAD, /, HTTP/1.1, 200, 0.022115 139.162.106.181, 2017-09-14 00:25:05, GET, /, HTTP/1.1, 303, 0.015381 139.162.106.181, 2017-09-14 00:25:05, GET, /user/login, HTTP/1.1, 200, 0.020568 63.143.42.248, 2017-09-14 00:34:15, HEAD, /, HTTP/1.1, 200, 0.021668 63.143.42.248, 2017-09-14 00:49:15, HEAD, /, HTTP/1.1, 200, 0.021978 63.143.42.248, 2017-09-14 01:04:15, HEAD, /, HTTP/1.1, 200, 0.022382 63.143.42.248, 2017-09-14 01:10:26, HEAD, /, HTTP/1.1, 200, 0.022271 63.143.42.248, 2017-09-14 01:25:26, HEAD, /, HTTP/1.1, 200, 0.024839 63.143.42.248, 2017-09-14 01:40:25, HEAD, /, HTTP/1.1, 200, 0.022224 63.143.42.248, 2017-09-14 01:55:25, HEAD, /, HTTP/1.1, 200, 0.021916 63.143.42.248 is UptimeRobot, and the 139.162.106.181 is probably serving somebody doing probes. Nothing in web2py.log is anything but normal, and in /var/log/messages the only thing in the timeframe is the regular DHCP update, and plenty of those happened while the server was up (about every 25 minutes to 30 minutes). I don't recall that Rocket hung up much when we were running on port 80 (before we got our certs), but we didn't have UptimeRobot set up at that point. /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.
