cherrypy

wendell

How do I use cherrypy? I want to move my cherrypy apps from wbfct**n. Do I need to have the uWSGI application run cherrypy as an "sub-application"? I see references about how to "run wsgi apps under cherrypy", but that seems backwards. Or can I just run cherrypy in place of uWSGI?
Thanks,
Wendell

sean

CherryPy has a decent web server built-in so you can run it without uwsgi. Here's an example:

Create a shell user if you haven't done so already.
Create a Proxy Port app and assign your shell user to it and make a note of the port assignment after you save the app. In the rest of this example, I'll refer to the app as "myapp" and the assigned port as "54321".
Assign the proxy port app to a site route.
SSH into your server as your shell user
Create a Python environment for CherryPy, eg: cd ~/apps/myapp; python3.6 -m venv env; source env/bin/activate
Install CherryPy and its dependencies: pip install cherrypy

Create a new file ~/apps/myapp/app.py like so (be sure to change the port number in line 2):

import cherrypy
cherrypy.config.update({'server.socket_port': 54321})

class HelloWorld(object):
    @cherrypy.expose
    def index(self):
        return "Hello World!"

cherrypy.quickstart(HelloWorld())

Once that's all done, you can start the server with: python ~/apps/myapp/app.py

Once the app is running, you should be able to view the site at the URL you configured in step 3 above.

Obviously, this isn't a practical app, but the basic idea of "install cherrypy and configure your app to use the panel's port assignment" is the key here.

swevolution

sean sorry to be picky but typo in "step 5 create an python env" (above) should be source env/bin/activate (slash missing)

wendell

Yes! Thank you, those instructions were just what I was looking for (i.e., don't run uWSGI, and use server.socket_port).
BTW, I had to rename uwsgi.ini, otherwise there was a 'uwsgi --ini' that kept running. Every time I killed them, four of them would restart. I even commented out the crontab entry, but no luck. What was it that was restarting all those uwsgi processes, and how do I tell it to do the same but with my new cherrypy server?

sean

wendell

What was it that was restarting all those uwsgi processes

You were possibly terminating child processes before terminating the master process, so the master was spawning new children to replace them.

To shut down uwsgi gracefully you can issue a stop command to the master process:

~/apps/appname/env/bin/uwsgi --stop ~/apps/appname/tmp/uwsgi.pid

If that doesn't work, you can kill the master process:

kill -9 $( cat ~/apps/appname/tmp/uwsgi.pid )

The stop script provided by our uwsgi app installer handles all of that for you.

how do I tell it to do the same but with my new cherrypy server?

I'm interpreting this as "how do I make my cherrypy process restart automatically after it is terminated?".

My advice there would be to use a process manager like supervisord to do that for you. I'll be posting a HOWTO for that in the coming week, or that's the plan anyway 😃

wendell

I figured it was something like that; I ran the stop script but I think the pid file got deleted somehow.
Looking forward to using supervisord
Thanks again.

swevolution

Hi very useful post - Thanks!
I got your example going but I am hoping to have a start/stop/restart capability.
Is this something I will need to create myself eg:
Something like "nohup python app.py &" and get stdout and stderr redirected to log file area. Hope this is not too far off topic.
Or will everyone want the same feature?

sean

swevolution supervisord will give you that start/stop/restart capability, I will try to get that HOWTO posted soon.

In the meantime if you want to run the app in the background, we have daemonize installed so you can launch your app with that like:

daemonize -a -c /home/you/apps/appname \
          -e /home/you/logs/apps/appname/stderr.log \
          -o /home/you/logs/apps/appname/stdout.log \
          -p /home/you/logs/apps/appname/pid \
          /bin/python3.6 /home/you/apps/appname/app.py

Once it's running you can send a kill signal to the process to stop it:

kill $( cat /home/you/logs/apps/appname/pid )
rm /home/you/logs/apps/appname/pid

You can wrap those examples up into your own start and stop scripts, and then wrap those scripts up into a restart like stop; sleep 2; start.

swevolution

sean Thanks I can work out something along those lines.

2 More things:

How about waking up the site when the url is accessed. I have a few sites that are rarely used so I would be happy for them to stop when no one is using and get started ... do some work .. and stop waiting to be restarted by an access to the URL.
How do I deal with static data on my site - do I somehow connect a static app to my route - like the django model?

kurt

sean I'm following this discussion in the hope that a forthcoming supervisord HOWTO will be announced here 🙂

sean

swevolution How about waking up the site when the url is accessed. I have a few sites that are rarely used so I would be happy for them to stop when no one is using and get started ... do some work .. and stop waiting to be restarted by an access to the URL.

We don't have a system in place for that yet. WebFaction used a weird CGI setup to do that, but we want to find a better way. For now, you'll need to keep your app running.

swevolution How do I deal with static data on my site - do I somehow connect a static app to my route - like the django model?

Yep, exactly that!

Create a static-only app, or the equivalent symlink app pointing to your existing static directory.
Add that app to your site on whatever URI path your site needs, eg /static or whatever.

wendell

That daemonize thing seems interesting. How does it work with the venvpart? Should the start script (that runs daemonize) be within the virtual environment, or should be 'outside'? If not within the venv, does it need to use a custom PYTHONPATH that points to the venv's library location? Is there anything special about starting it from a cron script (i.e., does the cron script need to start the venv, and then the start script that's going to call daemonize)?

sean

wendell if you're using a virtualenv all you need to do is use the Python that's in your env, eg:

daemonize -a -c /home/you/apps/appname \
          -e /home/you/logs/apps/appname/stderr.log \
          -o /home/you/logs/apps/appname/stdout.log \
          -p /home/you/logs/apps/appname/pid \
          /home/you/apps/appname/env/bin/python3.6 /home/you/apps/appname/app.py

No PYTHONPATH or activate stuff is necessary. There's a lot of inaccurate info on the web that tells you that you need to activate your virtualenv to do this, do that, etc but it's almost never necessary.

swevolution

sean minor typo: python3.6 is in apps not app

sean

swevolution 👍 nice catch, fixed!

sean

swevolution no worries, that was a nice catch. Fixed now, thanks! ❤️