However, following the instructions doesn't seem to be working for me, I
can get the 502 condition to run the script, but I can't get the script
to successfully start cherry py. Here is the script:
#!/usr/bin/python
print "Content-type: text/html\r\n"
print """<html><head><META HTTP-EQUIV="Refresh"
CONTENT="1;URL=/"></head><body><a
hre="/">Restarting.</a></body></html>"""
import os
os.setpgid( os.getpid(), 0 )
os.system( '/usr/bin/python /home/cliffhanger/Credit/start-credit.py &')
When I try to run this from the cgi directory, I get this error from
CherryPy:
TurboGears requires autoreload.package to be set. It can be an empty
value, which will use CherryPy's default behavior which is to check
every module. Setting an actual package makes the check much faster.
The above doesn't happen when I try to start it from the project
directory. Any idea what I need to do to get that working?
Thanks
Iain
This condition seems to be caused by a lack of a dev.cfg when TG is
looking for it. TG decides to use dev.cfg or prod.cfg based on
whether or not it can find setup.py. setup.py exists in your dev
directory and so does dev.cfg -- but in your deployment, setup.py
still exists but there isn't a dev.cfg. Could you test this out: Go
to your deployment directory, rename setup.py to setup.py-bak and then
try and start your app.
Please post back to the list with your results.
I belive this to be true because if I delete dev.cfg and start a
project I get the same error. If I start the project and specify the
prod.cfg it works as expected. The 3rd belief is from what I was told
on IRC and that was you don't want to run autoreload in product -- so
I think it is a bug. I invalidated the original report, because as it
was written -- it was wrong. As I've just described it.
rm/rename dev.cfg
rm/rename setup.py
try and start project -- boom
try and start project (specify prod.cfg) -- boom
put dev.cfg back
try and start project -- boom
try and start project (specify prod.cfg) -- boom
restore setup.py
try and start project -- golden
try and start project (specify prod.cfg) -- golden
at least that what happens on Ubuntu 6.10 w/ TG 1.0b2 and a quickstart
project with the defaults selected.
-Jeff
Thanks Jeff. I'll try all that out and report back. Now why wouldn't you
want to use autoreload in production? Is autoreload just Cherrypy's
autorestart on file save? ( that would make sense then I suppose. )
Gotta say, I am not a fan of CherryPy's habit of killing itself on
errors though. I'd much rather see an error message printed and the damn
thing keep trucking. :/
Iain
Ok, I do indeed have to either:
- call the start script with prod.cfg as a command line option
- delete setup.py
Further, while removing setup.py works iff the cgi script is being
called from within the project directory, it was still failing if I
switched to a different directory with the same autoreload message. The
only way I have managed to make the cgi script work when called from
wherever is to have this in my cgi:
os.system( 'python /home/cliffhanger/Credit/start-credit.py /home/cliffhanger/Credit/prod.cfg')
Now am I doing something wrong or does this means the docs on the cgi
hack just do not work as they are on Ubuntu? Been a bit of a headache
getting CherryPy to stay up, but considering how easily it goes down on
an unfound bug ... I would think it will frequently be an issue that
people are deploying with less than full control over where and how they
get to use CGI.
Thanks for the tips
Iain
Iain
You could try one of the tools I listed in my message from yesterday, "Options
for controlling the CherryPy process". I think the autostart.cgi solution is a
bit clumsy anyway.
Chris
I am quite new to TG and the autoreload advice came from the IRC not
personal experience. If it is correct, which I am currently assuming,
experience tells me their would be a performance penalty since
autoreload has to monitor file date/times to try and tell if needs to
reload a module. This would require extra disk accesses, hence the
performance penalty.
Since I haven't used it in production yet, nor read the code to fully
understand autoreload this is a Wild A$$ Guess (WAG) and my statement
should be viewed with suspicion.<g> Maybe someone with more concrete
knowledge about autoreload will jump in and add to the conversation.
> Gotta say, I am not a fan of CherryPy's habit of killing itself on
> errors though. I'd much rather see an error message printed and the damn
> thing keep trucking. :/
My plan is to run it through mod_python for production. I haven't
tried it yet though so I can't comment with any authority about it vs
other methods.
> Iain
>
>
>
>
> >
>
--
Jeff Hinrichs
Dundee Media & Technology, Inc
j
I'm not a fan of that either, which is why I spent many, many hours
making sure it doesn't. If you're experiencing "CherryPy killing
itself" (and not just Apache killing it due to inactivity), please file
a bug ticket at http://www.cherrypy.org/newticket (login as
guest/cherrypy).
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org