Lost stdout and stderr on fcgi with Django
I am running Django on a centos box using lighttpd and fastcgi. I found that if I didn't daemonize the fastcgi process and did not specify a socket name to the manage.py script that the fcgi handlers cooperated better and was able to place all of the fcgi process under the control of lighttpd and thus multiple sockets are created, load balancing happens and the fcgi processes are started and stopped by lighttpd when it starts and stops. The problem is that I am loosing stdout and stderr. In django/core/servers/fastcgi.py stdout and stderr are only honored by the runfcgi command IF you are going to daemonize. So I poked at the code and added this else clause at line 166: if daemonize: from django.utils.daemonize import become_daemon become_daemon(our_home_dir=options["workdir"], **daemon_kwargs) + else: + if options['outlog']: + so = open(options['outlog'], 'a+', 0) + os.dup2(so.fileno(), sys.stdout.fileno()) + if options['errlog']: + se = open(err_log, 'a+', 0) + os.dup2(se.fileno(), sys.stderr.fileno()) At which point I started getting the stdout and stderr messages. But that seems to have broken something else with the fcgi setup. So I obviously missed something about this. Any suggestions? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How nicely does django play in a distributed environment?
If you consider that Django started as an application for the news paper industry and the associated sites you might get a reasonable guess at answering your own question. I agree with all the other posts in that correctly building the infrastructure and properly engineering your application to be able to scale correctly is still left as an exercise for the reader. I am on the learning curve for Django myself and have a lot of unreasonably high goals for my pitiful little site. I surveyed all the frameworks I could find, read source, kicked the tires and then jumped on the Django band wagon. I am still mucking around down in the muck trying to get the foundation set up nice and sound. I have not been dissapointed with the code and engineering it all looks pretty darn good. The docs and especially solid enterprise grade examples are seriously lacking. So I am being forced to code crawl for some of the answers. It isn't a 1 week project from nothing to sizzling web site. But I am sure Django is an excellent framework to start with. + Leeland --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Lost stdout and stderr on fcgi with Django
I am going to submit this as a bug. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Is there any Django module like ViewCV for svn repositories?
I want to have a source code repository view on my Django site. I can not find any such module available. Mostly I want something like ViewCV with a couple of twists (user authentication, group permissions to view sections, tagging, etc.) In poking around I couldn't find any example python-svn implementations either. Of course then I rememberd "batteries built in" and sure enough there is a libsvn (although there are no docs or examples for this for this anywhere I can find even with google's help). Pointers, comments, suggestions? Thanks in advance!! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Capturing full URL string
I read this with great interest. It actually will save me time on my project. I will be encountering this behavior shortly. Thank you! Please, please submit a bug report on this with all the details here. If people do not submit bug reports future user of Django will eventually have the same problem and loose hours and hours searching for the cause (like Karen, Matthias, Gregor and yourself just did). Make that hard work you just did troubleshooting this count! + Leeland On Jun 4, 1:35 pm, John M <[EMAIL PROTECTED]> wrote: > Well, thank God you took a look at the code and agreed on my > findings. I'll just adjust my urls.py for now. > > Should I submit a bug report? (it'd be my first :) ) > > Thanks again for your time on this, I'm glad it was a bug and not my > mis-standing of django or the way this all works together. Now I can > move on a continue my app. > > John > > On Jun 4, 12:59 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > > > On Wed, Jun 4, 2008 at 2:03 PM, John M <[EMAIL PROTECTED]> wrote: > > > Yes, I understand that, and I think it's a good thing, but when it > > > redirects, it mangles the parameters, would you agree? > > > Yes, I think that's a bug in Django. The code that is doing the > > APPEND_SLASH handling tries to use request.GET.urlencode() to restore the > > original query parameters to the new url it has generated (specifically > > here:http://code.djangoproject.com/browser/django/trunk/django/middleware/...). > > However this fails to reconstitute the original query parameters when they > > were not in fact valid utf-8 to begin with (as your info_hash is not). Back > > when the GET QueryDict was constructed, this code: > > >http://code.djangoproject.com/browser/django/trunk/django/http/__init... > > > took the info_hash bytestring with repr > > '\x10\xc2\xe1\x96\xe0\x8d\x90\x05\xb7\xdf\xc6\xbc\x8e\xc2\x15\xe4=`\xcc\x84' > > and generated the unicode string with repr > > u'\x10\ufffd\ufffd\ufffd\x05\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\u0304' in > > its place. The request was assumed to be encoded in utf-8 for want of any > > better information. All those '\ufffd's are the Unicode replacement > > character, indicating that the input bytestring contained invalid utf-8 > > sequences. (For example, while the first byte \x10 is a valid 1-byte utf-8 > > sequence, the next two bytes \xc2 \xe1 are not. \xc2 is a valid first byte > > for a 2-byte sequence, but the 2nd byte must then begin with binary 10, > > where \xe1 begins binary 11. So those two bytes are tossed and '\ufffd' put > > in their place.) At this point there is no way to go back to the original > > input since generating the replacement char in place of invalid input throws > > away the original information. When the APPEND_SLASH code tries to > > urlencode() this unicode version of the query string, you see a lot of > > %EF%BF%BD because \xef\xbf\xbd is the 3-byte utf-8 encoding of the Unicode > > replacement character \ufffd. Clear as mud? > > > Anyway I think line 83 of django/middleware/common.py should be: > > > newurl += '?' + request.META['QUERY_STRING'] > > > instead of: > > > newurl += '?' + request.GET.urlencode() > > > That will ensure that the query parameters included in the redirect url are > > identical to what was included in the original url. > > > Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Question about Form Wizard
I am a new Django person as well. There is one other point about storing data in sessions. If you expect the site to grow you should put the session data in a back-end database. This will allow multiple servers to access the data. This is important if you ever want to have load balanced servers where more then one system will be tasked with rendering the next request. For a commercial site I did we created an entirely separate database table that stored incomplete form data. The table had fields for ALL of the required final data plus a user ID key (some vital part of unique information for that person, which was entered first when they started the processes) and a last updated date field. When work was done it the last updated field was updated (even if they just logged in and reviewed their status). Then we only needed to provide a login id so they could comeback any time to continue updating. They could also go to any page or stage of the input process because the data could be gathered based on the login credentials. This kept the data out of the sessions. We also had to have a back end process which cleaned up the table of any incomplete work that hadn't been accessed in 3 months. + Leeland --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
At what point is the WSGI request or server object available?
Sorry if this seems obvious I am a new comer to Django development. There are attributes I want to get at in the request or WSGI server objects to test if I should set up some specialized channels in my Django application. Problem is neither of these seem to be available until I get to the view method call. Specifically what I am trying to do is figure out if the server has been run as a mod_python, FCGI process, AJP process or by the built in test server. Then take the appropriate actions to so that print goes to the server's access logs, print >> sys.stderr goes to the server's error logs. I'd also like to automatically get the python logger doing the same. I have found that in a given view I can do something like if 'wsgi.errors' in request.META: # do setup work here I can't seem to put this code anywhere else (like in my settings.py file) where it can get picked up by the whole system. I am sure I am missing something here that is probably obvious and silly. Thanks in advance! + Leeland --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: python strings containing backslashes
I would use a raw string like this" string.rfind(r'\\') The raw string makes sure there is no additional escaped special characters. But you still need to escape the backslash. Here is a good read on all this: http://www.python.org/doc/current/ref/strings.html + Leeland --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---