just tried, works ok for me. note: DISABLED workers are put to a "sleepier" state checking on status updates at growing intervals. i.e. if you disabled a worker, it will with default values: - sleep 3 seconds, then, if the status is not updated - sleep 6 seconds, then, if the status is not updated - sleep 9 seconds, "" - sleep 12 seconds, "" - sleep 15 seconds, "" - sleep 18 seconds, "" - sleep 21 seconds, "" - sleep 24 seconds, "" - sleep 30 seconds, "" - after that, it continues to check for updates only every 30 seconds
It's possible that you enabled the scheduler but not waited a little time to let it "catch up" with status updates ? A Question: > Is there a way to start a worker process from within Web2py? > I suppose it is possible. > It isn't so convenient to get a commandline sometimes. > Nope. Scheduler is supposed to be a completely separated process from the webserver one, and a process that basically never dies (that's why there is no scheduler implementation around (celery, dj, rq, tq, resque, pyres, beanstalkd, etc) that is "embedded" in the webserver). If it was embedded, you'll suffer from the same limitations a webserver has (timeouts, and resources "spent" on doing one thing when you want your pages to react faster). No-one is stopping you from executing a task e.g. with an ajax call to another page: but you're using the scheduler because you want to keep the webserver "snappy" and because you may queue tasks that last longer than the default timeout imposed on the webserver (remember, webserver are basically "engineered" to stop a function that is taking too much time to free up resources for other users requesting other pages). In addition, "Advanced" webservers (nginx, apache, etc) reap child processes when they see them last longer than n seconds - again - to free up resources. If you were going to start the scheduler as a child process of the webserver, it may get terminated by the webserver after a certain timeout, and at that point it's going to be really unuseful! You can use while developing *web2py.py -a 'yourpassword' -K yourapp -X* to let web2py.py launch a separate process and avoid to start the scheduler in another shell, but that's all about the shortcuts available (in addition of starting a scheduler from the web2py default widget). Behind the curtains *web2py.py -a 'yourpassword' -K yourapp -X* basically does a *web2py.py -K yourappname* followed by a *web2py.py -a 'yourpassword' * . There's no "further magic" web2py can do. In "production" environments you *have* to start the scheduler as an *out-of-band process* (web2py.py -K yourapp), else all the benefits of using it are zeroed --
