I recently converted my Wordpress install to a Django based solution
hosted on Dreamhost.  This worked all fine and well until Dreamhost
announced the new svn over http support.  I was excited to use the new
svn over http so I installed it via the admin console into the same
directory as my Django project.  The Dreamhost panel informed me that
in order to add the svn support it would have to change my DNS
configuration.  And that this change might take up to two days to take
affect.

A few hours afterwards I noticed that my Django site was no longer
returning.  The browser would just spin and timeout with some sort of
Apache based 500 error.  To trouble shoot I took Django out of the mix
by clearing my .htaccess file and tried to hit a very simple hello.fcgi
file.  Same issue.  I have since removed the svn from the domain via
the panel, but the problem still persists.

As far as I can tell the only thing that changed, and could have cased
this is the addition of svn, and the change to the DNS/Virtual Host.

This has not affected and subdomains.  To see this in action
http://dev.socialistsoftware.com/ is a development version of my Django
project, and works just fine.
http://www.socialistsoftware.com/hello.fcgi is a simple fcgi script
that does not work on the main site but works alright on the dev site
http://dev.socialistsoftware.com/hello.fcgi

So the point of this message is to warn other Django/Dreamhost users to
avoid using the new svn on your current domain.  However it looks like
adding it to a subdomain should be fine.

Dreamhost has now fixed this problem

"""
Our apologies for the delays.  We did have SVN problems at the time it
was implemented, but our admin team has found the source and rectified
the situation.  All Subversion should now be compatible with PHP and
PHP
as CGI domains.

If there is anything more we can help you with, please let us know and
we
will be more than happy to accommodate.
"""

I'm having the same issue - 500 errors trying to run hello.fcgi...
I didn't install any fancy new svn however. So you're saying the
problem just solved itself? :-\

I've been experiencing the same with Django on Dreamhost. But after some
frustrating 500 errors, my first Django app miraculously started to run
fine. I just waited a few minutes.

I noticed that once, I would get 500 after some compile error in my code. I
don't get 500 for every compilation error, but occasionally, an error seems
to cause 500 and timeouts. But then, it just solves itself after a wait.

Hans-Christian

Make sure your code actually works before trying FastCGI. Remember to
kill FastCGI processes after modifications (or wait for them to reload
"naturally" --- takes a while). You can look them up using "ps -ef" and
kill them using "killall python" (or "killall python2.4", if you use
Python 2.4).

Thanks,

Eugene

Eugine,
I also use Dreamhost( and it works great) but have a problem how to
kill the correct process.
When I try "killall python" or "killall python2.4" I receive "no
process killed".
Why?
When I use ps ax to see the process number, I can see a lot of
/usr/bin/python django.fcgi and I do not know what is the right process
to be killed.Any idea?

Thank you for help
Regards,
L.

What I use sometimes on Dreamhost is this:

pkill python;pkill fcgi.py

"pkill python" refreshes the process', so I can hit reload on the
browser and see the changed code. While "pkill fcgi.py" make the
"Mysql server has gone away" problems disappear.

Dreamhost hasn't been good to me. I will be switching hosts soon...
can't have such unreliable apps live.

On 3/7/06, PythonistL <pyt...@hope.cz> wrote:

--
Julio Nobrega - http://www.inerciasensorial.com.br

First make sure that there are any using "ps -ef". If you see "no
proccess killed", do "ps -ef" again and compare with previous list. The
chances are your processes were recycled already (PID is different). If
it happens regularly --- most probably your processes crashed somehow
(bug in the code?).

If you run several web sites from one account, you cannot tell which
process serves a given web site. I kill all of them. Alternatively use
different users for different web sites --- it is more organized.

Thanks,

Eugene

Eugene,
thank you for your reply.
You say"
 If you run several web sites from one account, you cannot tell which
process serves a given web site. I kill all of them"
But how can I kill ALL of them?
One by one something like:
kill processNumber
?
Thank you for reply
L

On 3/8/06, PythonistL <pyt...@hope.cz> wrote:

pkill is your friend.

I use "pkill -9 python2.4" on abovenet for most code changes.

--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
+91-9867-359-701

or use a little shell scripting, like

ps aux | grep python2.4 | awk '{print $2}' | xargs kill

or something like that..

(i have to admit, the pkill solution looks simpler :))

gabor

On Wed, 8 Mar 2006 19:43:21 +0530

I've actually had pretty decent success with

killall -USR1 the_process_you_want_to_die

This is supposed to signal the process it needs a restart so that the
next request in will be a process running your new code.

- jmj