> > Only other things I can think of is that are using an IP address in the > VirtualHost definition rather than a '*' and the IP address by which the > VPS is being contacted is changing. > The IP address hasn't changed but that seems to have worked. Also sorry for the slow reply but with the issue being so intermittent I waited awhile to see if it worked and then forgot about the issue when it didn't come up again.
On Tuesday, December 3, 2013 3:13:10 PM UTC-8, Graham Dumpleton wrote: > > If restarting the entire VPS when the Apache configuration wasn't changed > didn't fix the issue, that would suggest that it has nothing to do with > Apache or its configuration, but that inbound port access is being blocked > outside of the VPS. > > From a different box than the VPS, preferably not on the same network as > the VPS is running, run: > > traceroute test.example.com -p 8880 > > Using the actual external hostname or IP of the VPS and the port Apache is > meant to be listening on. > > Also do that from the VPS itself. > > Report the results. > > Only other things I can think of is that are using an IP address in the > VirtualHost definition rather than a '*' and the IP address by which the > VPS is being contacted is changing. > > Do not hardwire VirtualHost to a specific IP unless you have a specific > requirement. > > Graham > > On 04/12/2013, at 4:08 AM, Jestin Brooks <[email protected] <javascript:>> > wrote: > > its running on a VPS > > restarting doesn't fix it > > I'm not sure how to tell if its a zombie process but heres one of them > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > apache 1842 0.0 3.4 420656 17116 ? S Dec02 > 0:00 /usr/sbin/httpd > > The flask app is a website that displays data collected from sensors > > On Monday, December 2, 2013 2:41:25 PM UTC-8, Graham Dumpleton wrote: >> >> What is the system you are running on? Is it a personal machine, a VPS, a >> hosted service? >> >> Does restarting the operating system resolve the issue and allow the port >> to be used again? >> >> For the process that lsof shows are still using the port, if you run 'ps' >> (ps auxwww), what is the state of the process? Are they zombie processes? >> >> What does the Flask application do? >> >> Graham >> >> On 03/12/2013, at 4:55 AM, Jestin Brooks <[email protected]> wrote: >> >> My Flask and mod_wsgi app seems to be breaking ports. Every month or so >> my page will stop loading and I get a "Google Chrome could not connect to " >> message, but moving it to a new port fixes it. I've checked the apache log >> and there doesn't seem to be anything wrong there. If I stop apache from >> listening to the port and run my dev version of the Flask app on one of the >> ports that the live version has previously used I get the same "Google >> Chrome could not connect to " message. While apache is listening Netstat >> shows that the port is being listened to by apache and lsof -i returns a >> bunch of apache processes that are using the port. I'm not sure if any of >> that is normal for mod_wsgi. If I remove the port from apache both netstat >> and lsof return nothing but the port still doesn't work for mod_wsgi or >> flask. >> >> Here is the mod_wsgi part of my apache config file with the ip, domain, >> and user/group changed >> >> <VirtualHost 0.0.0.0:8880>ServerName test.example.comDocumentRoot >> /var/www/html >> WSGIDaemonProcess dash user=user group=group threads=5 >> WSGIScriptAlias / /var/www/html/dash/dashboard.wsgi >> <Directory /var/www/html/dash> >> WSGIProcessGroup dash >> WSGIApplicationGroup %{GLOBAL} >> Order deny,allow >> Allow from all</Directory> >> # records regular flask errorsErrorLog /var/www/html/dash/error.logLogLevel >> warn >> >> >> Here is my wsgi file >> >> import osimport sys >> # location of flask app >> sys.path.insert(0, '/var/www/flask/dashboard') >> >> from dashboard import app as application >> # logs python errors at production.logif not application.debug: >> import logging >> this_dir = os.path.dirname(__file__) >> log_file = os.path.join(this_dir, 'production.log') >> file_handler = logging.FileHandler(log_file) >> file_handler.setLevel(logging.WARNING) >> application.logger.addHandler(file_handler) >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
