A clarification and a few other comments below. On 25/03/2015, at 11:31 AM, Joshua Rodriguez <[email protected]> wrote:
> Moving this discussion from StackOverflow. Here's my original question: > > I'm using mod_wsgi-express to serve a simple Flask app on a CentOS 6 server. > The app is currently used pretty infrequently. > > I'm having an issue where every few days, the app will crash, either serving > up 500 errors or not responding at all. This doesn't seem related to load or > use. > > Looking through the error log, I'm seeing occasional "[notice] caught > SIGTERM, shutting down" messages, after which it appears mod_wsgi-express > restarts. I don't know why this is happening. > Are they are other messages around that point in the log output? It may help to ensure using '--log-level info' if on most recent mod_wsgi-express version as will give more information about what mod_wsgi processes are doing in error log. Until recently it defaulted to 'info' level, but had to change it to 'warn' due to noisy mod_ssl when using HTTPS. Also, is mod_wsgi-express being run under 'supervisord' or something else to ensure it stays up if not using mod_wsgi-express with the generated 'apachectl' script? A message of just: [Wed Mar 25 11:46:10 2015] [notice] caught SIGTERM, shutting down generally implies that Apache as a whole has been told to shutdown. If it is being restarted that would suggest the use of some supervisor to keep it running. > I'm also getting this message: > > [error] (2)No such file or directory: mod_wsgi (pid=24550, > process='localhost:8080', application=''): Call to fopen() failed ff or > '/tmp/mod_wsgi-localhost:8080:14699/handler.wsgi'. It is this specific error I was referring to when said 500 error and which I believe is the result of the server root directory being in /tmp and why --server-root should be used to use a more permanent location where the OS will not arbitrarily remove files. > I've tried running mod_wsgi-express with both gdb and pdb debuggers enabled > and haven't seen any bugs related to the actual execution of the Python > script. > > I also got a > > [info] [client 137.78.237.31] (104)Connection reset by peer: > core_output_filter: writing data to the network This can be normal as can be logged when the HTTP client has dropped the connection before it has read the complete response. Can get this a lot if dealing with slow mobile web clients. > which kicked off hundreds of > > [notice] child pid 15952 exit signal Segmentation fault (11) > over the course of a couple days. > If however the segmentation fault is always associated with the core_output_filter message that is a bigger problem. The use of '--log-level info' will result in process IDs for mod_wsgi daemon process being logged, plus other messages and so we can see what process is actually crashing. Technically the core_output_filter message could come from the mod_wsgi daemon processes as well, but if that occurs it would generally imply that the Apache child worker process was what was crashing. BTW, what version of mod_wsgi-express are you using? And what version of Apache was it built against? > These messages all seem to happen randomly and independent of each other. The > only consistent thing is the SIGTERM signal happening every so often. > > I'm confused as to what's going on. The implementation seems pretty simple - > it's a simple tool that validates metadata in an uploaded file. > > ---- NOTE: I have moved the server root to a non-temp directory. I'll see if > that helps anything. I also was not running gbd in debug mode. > > Graham -- 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.
