Code

Opened 6 years ago

Closed 5 years ago

#6130 closed (duplicate)

nginx + flup does not work with trunk revisions after 6775

Reported by: Grigoriy Owned by: nobody
Component: Template system Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Any django site does not work with nginx/flup if django revision is more than 6775
Error message is:

Unhandled Exception
An unhandled exception was thrown by the application.

No error traceback is generated.

I've compared 6775 and 6778 and found that changes in line 807 of django/template/init.py is the reason of troubles.
When I add line 807 from r6778 to r6775 my site crashes.
http://code.djangoproject.com/changeset?old=django%2Ftrunk%406775&new=django%2Ftrunk%406778 diff of 6775 and 6778

Note that under the debug server my projects work fine with all django revisions.

Attachments (0)

Change History (3)

comment:1 Changed 6 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

Dupe of #6063

comment:2 Changed 5 years ago by qingran

  • Resolution duplicate deleted
  • Status changed from closed to reopened

I got the following error message from the nginx's error log just now, and it gave the visitor a page only with notice, Unhandled Exception An unhandled exception was thrown by the application.

2009/05/05 22:52:26 [error] 13881#0: *166350 FastCGI sent in stderr: "Traceback (most recent call last):

File "/usr/local/lib/python2.5/site-packages/flup-1.0.1-py2.5.egg/flup/server/fcgi_base.py", line 558, in run

protocolStatus, appStatus = self.server.handler(self)

File "/usr/local/lib/python2.5/site-packages/flup-1.0.1-py2.5.egg/flup/server/fcgi_base.py", line 1116, in handler

result = self.application(environ, start_response)

File "/usr/local/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 246, in call

signals.request_finished.send(sender=self.class)

File "/usr/local/lib/python2.5/site-packages/django/dispatch/dispatcher.py", line 148, in send

response = receiver(signal=self, sender=sender, named)

File "/usr/local/lib/python2.5/site-packages/django/db/init.py", line 46, in close_connection

connection.close()

File "/usr/local/lib/python2.5/site-packages/django/db/backends/init.py", line 51, in close

self.connection.close()

The information of my enviorment is listed as follows:
OS: FreeBSD-6.2 release amd64
Django: 1.0.2
Python: 2.5.2_2
Flup: 1.0.1
Webserver: nginx-0.6.36
Fastcgi startup command: /usr/local/bin/python manage.py runfcgi method=threaded umask=000 socket=/var/run/fastcgi.sock pidfile=/var/run/fastcgi.pid outlog=/var/log/fastcgi.output errlog=/var/log/fastcgi.error minspare=5 maxspare=18 maxrequests=65 maxchildren=64

comment:3 Changed 5 years ago by ramiro

  • Resolution set to duplicate
  • Status changed from reopened to closed

Plase don't reopen arbitrary already closed tickets that only share some (one?) symptoms with the problem you are seeing. This ticket was closed as a duplicate of another one that described a well-defined Django bug that was since then fixed and that fix ins included in the version of Django you are using. Your problem seems to be another different one.

Open another ticket for your problem, but use WikiFormatting and preview it at least once so the report (traceback, environment information) is legible.

Also, don't forget to add what's the value of the DEBUG setting when you see this behavior.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.