Problems using autostart.cgi

4 views
Skip to first unread message

iain duncan

unread,
Dec 4, 2006, 6:19:17 PM12/4/06
to turbo...@googlegroups.com
I'm trying to get the autostart cgi hack to work to kick start CherryPy
( why oh why does it have to close itself on any kind of error
anyway? ).

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

Karl Guertin

unread,
Dec 4, 2006, 6:36:15 PM12/4/06
to turbo...@googlegroups.com
On 12/4/06, iain duncan <iaind...@telus.net> wrote:
> 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?

http://trac.turbogears.org/turbogears/ticket/1186

Jeff Hinrichs - DM&T

unread,
Dec 4, 2006, 9:50:10 PM12/4/06
to turbo...@googlegroups.com

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

iain duncan

unread,
Dec 5, 2006, 1:45:15 AM12/5/06
to turbo...@googlegroups.com

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

iain duncan

unread,
Dec 5, 2006, 3:06:04 AM12/5/06
to turbo...@googlegroups.com

> 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.

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 duncan

unread,
Dec 5, 2006, 3:31:52 AM12/5/06
to turbo...@googlegroups.com
So now my problem is that the apache user can't run the start script
without the right permissions. I'm not sure what the recommended
solution is to this. On ubuntu, by default apache runs as user www-data
and has pretty limited permissions, which I guess is as it should be.
Any tips on that?

Iain

Christopher Arndt

unread,
Dec 5, 2006, 4:39:08 AM12/5/06
to turbo...@googlegroups.com
iain duncan schrieb:

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

Jeff Hinrichs - DM&T

unread,
Dec 5, 2006, 9:15:36 AM12/5/06
to turbo...@googlegroups.com

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

fumanchu

unread,
Dec 5, 2006, 11:44:25 AM12/5/06
to TurboGears
iain duncan wrote:
> 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. :/

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

Reply all
Reply to author
Forward
0 new messages