How does one debug a FastCGI application? I've got an app that's dying but I can't figure out why, even though it's likely throwing a stack trace on stderr. Running it from the commandline results in an error saying:
RuntimeError: No FastCGI Environment: 88 - Socket operation on non-socket
How do I set up a 'FastCGI Environtment' for debugging purposes? It's not my app - it's a 3rd party open source app - so I'd rather avoid adding in a bunch of logging to figure out what's going wrong.
If it matters, the app is Python, but FastCGI is FastCGI, right? Is there a shim or something to let you invoke a fastcgi program from the commandline and hook it up to the terminal so you can see its stdout/stderr?
It does matter that the application is Python; your question is really "how do I debug Python when I'm not starting the script myself".
You want to use a remote debugger. The excellent WinPDB has some documentation on embedded debugging which you should be able to use to attach to your FastCGI application and step through it.
Related
I am working a project, that creates an django app over a request. Since the webserver apache needs to be restarted to add new files created. I tried following:
1) Django request_complete Signals: This is not good way because I dont want my server to be restarting on every request complete
2) threading.Time:I tried to run a function with some delay so that it allows complete the current request.
This is not working giving following error:
RuntimeError at /apps/37f63340-2984-40b1-a728-1cf3d0820ae6/
threads can only be started once
Please suggest me way to solve this problem.
You tagged this with "webfaction" so I'm going to assume you're using WebFaction's default mod_wsgi setup.
If that's the case, then you can restart the mod_wsgi daemon processes, instead of restarting Apache itself, as described in the mod_wsgi documentation: Reloading Source Code
When the code for my python WSGI applicaiton changes should I use apache2's reload or graceful restart feature?
Currently we use reload, but have noticed that sometimes the application does not load properly and errors pertaining to missing modules are logged to the error files even though the modules have existed for a long time.
If you can, you should probably use graceful. But if your application is not exiting correctly you may have to force it with just restart.
For wsgi, you should try running in daemon mode. When it is running in daemon mode, you can restart your service just by touching the wsgi file and updating its timestamp. This will reload all the code without restarting apache.
Here is more info: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
This is for django, but may be useful for your project: http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
The 'reload' and 'graceful' would have the same effect as far as reloading your web application. If you are seeing issues with imports like you describe, it is likely to be an issue in your application code with you having import order dependencies or import cycles. One sees this a lot with people using Django. Suggest you actually post an example of the error you are getting.
I get strange errors when trying to deploy a Flask app (v0.8). I'm using apache's mod_wsgi, as suggested in the docs (almost to the letter). What's strange is that on some requests (simply accessing / via browser), the application loads fine, but very often I get a resource load errors (can't fetch some css or image), and the error log shows something like Premature end of script headers: myapp.wsgi. Sometimes apache crashes with Internal Server Error. I'm trying to chase the problem but could not figure out what's the cause. My wsgi file looks simple:
from myapp import app as application
Any clues where to start looking?
If you are getting Premature end of script headers, you are using daemon mode and the daemon process is crashing with a seg fault or similar.
Make sure you aren't still loading mod_python.
Also try setting:
WSGIApplicationGroup %{GLOBAL}
to work around issues with Python C extension modules which aren't safe for sub interpreters.
See:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
and look for various reasons for crashes listed.
I am new to cherrypy, and can't seem to figure out how to have cherrypy emit a stacktrace or error message to my browser when an error occurs.
I am running cherrypy on apache with mod_wsgi, so its particularly annoying to dig through the apache error logs during development.
I am used to PHP, where errors are nicely output to the browser when your script crashes. It is a useful feature when debugging. How does one do this in CherryPy?
This section on logging in CherryPy doesn't seem to cover that, unless I'm missing something obvious.
The most important config setting which governs tracebacks in the browser is request.show_tracebacks. Set it to True to get tracebacks. Note that using the "production" config environment sets this to False. There may be other WSGI components you're using, or some feature of mod_wsgi or Apache which is also getting in the way, but I can't speak to those.
This question already has an answer here:
Testing for mysterious load errors in python/django
(1 answer)
Closed 3 years ago.
I am hosting a Django app on Apache using mod_python. Occasionally, I get some cryptic mod_python errors, usually of the ImportError variety, although not usually referring to the same module. The thing is, these seem to come up for a single forked subprocess, while the others operate fine, even when I force behavior that requires using the module that the problem process has errored on. Once the process encounters the error, it will always just serve the same traceback every time Apache chooses it to handle a request. (This is also a hassle, since my users don't necessarily report the error on the first occurrence, and once the process encounters the error.)
I know more about configuring Django than configuring Apache, but that won't get me anywhere since the request never reaches Django for processing. Ideally, I should solve the root problem, and that might involve my code, project, or machine configuration, but until then, I need help diagnosing and mitigating the problem.
Is there any way to configure the Apache logs to include a subprocess id?
Is there any way to force a subprocess to respawn if it has hit an error?
Are there any known issues relating to this that I should know about?
As a workaround, and assuming you are free to install new Apache modules on the server, you might try one of
mod_scgi
mod_fastcgi
mod_wsgi
instead. I use SCGI to connect an nginx frontend webserver to my Django apps, which highlights a major benefit (decoupling from the webserver). All of these packages are available in Debian, probably on RHELx as well.