The embed-mode script works great and allows us to use Supervisord- Thanks--
On Wednesday, August 15, 2012 11:44:18 AM UTC-4, Niphlod wrote: > > Because web2py lets you launch multiple schedulers with web2py.py -K > myapp,myapp or web2py.py -K myapp1,myapp2 the actual scheduler process is a > subprocess of the main one you launch with web2py.py. > > If you launch with the "external" method, as python gluon/scheduler.py -t > tasks.py -f .... etc no subprocess is spawned and then the PID reported on > the scheduler_worker table is the same one you have on "console". > > Obviously a scheduler spawns a process for every task processed (that's > the whole point of the scheduler) but there's no "master" spawning the > scheduler itself. > > BTW, I'm working on having the "embedded mode" to terminate all workers > processes spawned when the "master" is killed. It's on the feature list. > > PS: for the moment you can make a script to work as "embedded mode" and > with no subprocesses spawned. Place it in the same folder where web2py.py > lives. This will run a single scheduler process with no subprocesses > > #!/usr/bin/env python > # -*- coding: utf-8 -*- > from gluon.shell import run > from gluon import main > import logging > > logging.getLogger().setLevel(logging.INFO) > > if __name__ == '__main__': > code = "from gluon import current; current._scheduler.loop()" > app = 'myapp' > run(app,True,True,None,False,code) > > > > > On Wednesday, August 15, 2012 5:48:54 AM UTC+2, Yarin wrote: >> >> I'm trying to use supervisord to monitor scheduler workers. >> >> My supervisord.conf file: >> [program:my_scheduler] >> command={my_site_path}/web2py.py -K my_app >> >> When I launch supervisord, a worker shows up in the scheduler. However, >> when I compare the listed pid in the supervisord console, it doesn't match >> up with the pid of the worker as found in the worker name. Sure enough, >> when I stop or kill the process in supervisord, it has no effect on the >> worker, which keeps on ticking. Meanwhile, the 'killed' worker in the >> supervisord console now shows a pid = 0. >> >> This confuses me because when you launch a worker directly in a terminal >> window, it doesn't daemonize- so I don't understand why supervisord loses >> control of it, and why there are 2 different PIDs. Are there subprocesses >> being launched im not aware of, and if so does anyone have an idea of how >> supervisord can track them? >> >> >> --