This page lists the contents of file scripts/sessions2trash.py. Line
11 of the file is listed as
unlink(filename)
This line should be
os.unlink(filename)
This is also a bug in the web2py distribution.
I tried adding the errata to http://wiki.web2py.com/Errata_for_web2py_2nd_Edition_Book
after registering and logging in. The edit page, http://wiki.web2py.com/_edit_page/587,
failed to load with both Firefox (too many redirects) and Internet
Explorer (unknown error).
Here is a hint for using the book listed command
nohup python web2py.py -S yourapp -R scripts/sessions2trash.py &
in /etc/rc.local, to enable automatic start of this script on boot.
Make sure you change to the directory where web2py.py is first. For
exmaple if web2py.py is in /home/web2py then use
cd /home/web2py
first.
John Heenan
This hint is of course only relevant if you don't already use /etc/
rc.local to start up web2py. I use a scrpt in /etc/init.d instead to
start up web2py.
John Heenan
@hourly root *applications/admin/cron/expire_sessions.py
AND why page 123 provides an example of how to run web2py crontabs
from /etc/crontab (called 'hard cron' by web2py):
0-59/1 * * * * web2py cd /var/www/web2py/ && python web2py.py -C -D 1
>> /tmp/cron.output 2>&1
YET page 302 in the the deployment recipes section appears to prefer
keeping a python process lying around in memory to expire sessions
that is only used relatively infrequently.
I imagine most of us on this list are severely constrained with regard
to resources for live deployment of web2py. I use a 256MB VPS and make
sure I only run the absolute minimum number of processes. Some on this
list will have even even less memory available (such as if using
webfaction).
I have only one process running that goes above 3MB memory use: a
single persistent python process that runs all my web2py apps and uses
37MB of memory . The webserver (lighttpd) occupies 2.3MB and does not
fork. These memory sizes occupy RAM and swapped memory if not enough
RAM memory is available. The potential memory use of python is 236MB
(VSZ size).
Under these circumstances the web2py labelled 'soft cron' option is
attractive as no extra processes are spawned: the python process that
runs web2py runs web2py specific crontabs in web2py/applications/xxx/
cron/crontab.
John Heenan
I normally expire sessions in the model iteself. No cron and no
process.
This is confirmed from examining web2py/gluon/contrib/cron.py I see
that a Python Popen is executed. This forks off another process,
connects standard input, output and error and then waits.
This is overkill if the only task of a crontab is to expire sessions
using Python code and there is a goal to minimise memory hungry
processes occupying memory, no matter for how short, that might risk
bringing the swap file into use.
Massimo's way of expiring sessions from the model file is less
resource intensive, if Python code is used.
John Heenan
2010-01-06 15:15:13,876 - INFO - WEB2PY CRON (soft): Application: zgus
executing **applications/admin/cron/expire_sessions.py in /home/zgus/
web2py/web2py at 2010-01-06 15:15:13.876653
2010-01-06 15:15:14,636 - INFO - WEB2PY CRON Call returned: default
applications appear to be installed already
web2py Enterprise Web Framework
Created by Massimo Di Pierro, Copyright 2007-2009
Version 1.67.2 (2009-09-28 16:29:33)
Database drivers available: SQLite3
WARNING:root:GUI not available because Tk library is not installed
John Heenan