On Aug 11, 1:45 pm, Mike Orr <[email protected]> wrote: > So, how again do you test a uwsgi-daemon
I believe uWSGI supplies a Python module which can talk its native daemon protocol. They use this to allow systems like Twisted to talk to it I think. See: http://projects.unbit.it/uwsgi/wiki/RunOnTwisted > or mod_wsgi daemon site? In all the time that Apache/mod_wsgi has been around, there hasn't been any situation where having the ability to communicate direct to the daemon process, bypassing Apache server processes, would have been useful. Looking at the final WSGI environment dictionary passed to the WSGI application has always been enough. This is because the tight integration means that the WSGI environment is always being setup correctly and you don't get the problems with FASTCGI and HTTP proxies where the intermediary can subtly change things on the way through. Allowing direct access to the daemon process would also break down the security of the system if used on a shared hosting system and leave it open to attack due to way mod_wsgi works. The only time this issue ever comes up is where people try and push the line that mod_wsgi daemon mode is evil in some way because it uses what they see as a proprietary protocol rather than FASTCGI or HTTP. In practice it is never an issue. > With > PasteHTTPServer I can just fire up a text browser and send it an HTTP > request. Just like you can with Apache/mod_wsgi. ;-) > But what's kind of client can form a uWSGI or SCGI request? At this point am not sure what you are talking about since you are saying SCGI where as before you said mod_wsgi. I'll keep commenting in respect of mod_wsgi anyway. > It's not rare that I upgrade an app and restart it and it refuses to > start and Apache won't tell me why, the Supervisor log is empty and > there's nothing useful in the app error log. Which has nothing to do with what protocol is used across the socket between web server front end and daemon processes. For Apache/mod_wsgi, where stuff doesn't appear in the Apache error logs, it is usually because the WSGI application itself is capturing the exception and discarding it. Django in non debug mode is a classic case. You can only get the error messages if you set up a middleware to catch it and email it to you or explicitly log it. The only other cases are where the process outright crashes, but even then you still at least get a message saying that a segmentation fault occurred and if you up debug level to info in Apache you will get various other messages indicating processes died and restarted as well. Most people never read the mod_wsgi documentation on debugging and learn however that debug output can be increased. The default is not to be noisy else it fills up the Apache error logs. Finally, there was a bug which in certain virtual host configurations would cause logging from a SSL virtual host to go missing, but that has been fixed now. Graham > Sometimes I can run it in > development mode and see what the problem is, but other times it needs > the exact production environment; e.g., for a permission error where > my account can write a file but the www-data can't, or where it can't > open a log file because the directory containing it doesn't exist. So > a command-line client or browser plugin that can take a URL and send a > uWSGI or SCGI request would seem like a vital tool for troubleshooting > such installations, yet it doesn't seem to exist. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
