What if you cd trunk python setup.py install
? On Fri, Sep 17, 2010 at 10:54 AM, <[email protected]> wrote: > > I think you can do this. > > > > svn co http://svn.supervisord.org/supervisor/trunk/ > > easy_install trunk > > Thank you for the instructions. > > I got the following error: > NameError: global name 'log' is not defined > > I am pasting below the whole message > > > > easy_install trunk > Processing trunk > Running setup.py -q bdist_egg --dist-dir > /websites/libraries/supervisord/trunk/egg-dist-tmp-CbiY56 > Traceback (most recent call last): > File "/usr/bin/easy_install", line 7, in ? > sys.exit( > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 1670, in main > with_ei_usage(lambda: > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 1659, in with_ei_usage > return f() > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 1674, in <lambda> > distclass=DistributionWithoutHelpCommands, **kw > File "/usr/lib/python2.4/distutils/core.py", line 149, in setup > dist.run_commands() > File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 211, in run > self.easy_install(spec, not self.no_deps) > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 427, in easy_install > return self.install_item(None, spec, tmpdir, deps, True) > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 471, in install_item > dists = self.install_eggs(spec, download, tmpdir) > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 655, in install_eggs > return self.build_and_install(setup_script, setup_base) > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 930, in build_and_install > self.run_setup(setup_script, setup_base, args) > File > "/usr/lib/python2.4/site-packages/setuptools/command/easy_install.py", > line 919, in run_setup > run_setup(setup_script, args) > File "/usr/lib/python2.4/site-packages/setuptools/sandbox.py", line 26, > in run_setup > DirectorySandbox(setup_dir).run( > File "/usr/lib/python2.4/site-packages/setuptools/sandbox.py", line 63, > in run > return func() > File "/usr/lib/python2.4/site-packages/setuptools/sandbox.py", line 29, > in <lambda> > {'__file__':setup_script, '__name__':'__main__'} > File "setup.py", line 89, in ? > File "/usr/lib/python2.4/distutils/core.py", line 149, in setup > dist.run_commands() > File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands > self.run_command(cmd) > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File "/usr/lib/python2.4/site-packages/setuptools/command/bdist_egg.py", > line 167, in run > self.run_command("egg_info") > File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command > self.distribution.run_command(command) > File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", > line 171, in run > self.find_sources() > File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", > line 252, in find_sources > mm.run() > File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", > line 306, in run > self.add_defaults() > File "/usr/lib/python2.4/site-packages/setuptools/command/egg_info.py", > line 333, in add_defaults > rcfiles = list(walk_revctrl()) > File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", > line 45, in walk_revctrl > for item in ep.load()(dirname): > File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", > line 52, in _default_revctrl > for path in finder(dirname,path): > File "/usr/lib/python2.4/site-packages/setuptools/command/sdist.py", > line 98, in entries_finder > log.warn("unrecognized .svn/entries format in %s", dirname) > NameError: global name 'log' is not defined > > > > > On Fri, Sep 17, 2010 at 10:44 AM, <[email protected]> wrote: > > > >> > The changes for #1 are checked in to the trunk. This addresses the > >> > immediate bug not closing FCGI sockets on reload. > >> > >> I would like to test the trunk version. How do I install that version on > >> my Centos box; I am using easy_install. > >> > >> Thank you > >> > >> > >> > >> > > >> > Cheers, > >> > > >> > Roger > >> > > >> > On Thu, Sep 9, 2010 at 10:48 AM, Roger Hoover > >> > <[email protected]>wrote: > >> > > >> >> I currently see three options and I'm leaning toward number 1 but > >> >> welcome > >> >> input. > >> >> > >> >> 1) Always close the sockets when the number of processes in the group > >> >> hits > >> >> zero and figure out a way to do graceful restarts later. This > >> solution > >> >> is > >> >> simple and foolproof. > >> >> > >> >> 2) Create well defined process group hooks in Supervisor like > >> (something > >> >> like beforeStart, afterStart, beforeStop, afterStop, beforeRestart, > >> >> afterRestart, etc or a way of registering a callback after an async > >> >> event is > >> >> complete) so that process groups can implement custom behavior. This > >> >> would > >> >> be great but would require a lot of refactoring. There currently > >> isn't > >> >> a > >> >> single place in the code where this process group logic lives. For > >> >> example, > >> >> if you stop a process group through supervisorctl, the RPC interface > >> has > >> >> it's own logic for iterating through the processes in the group and > >> >> stopping > >> >> them. If you call 'reload' though supervisorctl, it puts supervisord > >> >> into > >> >> the RESTARTING state which later triggers a different code path for > >> >> stopping > >> >> all the processes in a group. The scope of this task seems to big > >> for > >> >> me to > >> >> take on at this point. > >> >> > >> >> 3) Change the default behavior to close sockets when the reference > >> count > >> >> hits zero as in #1 but leave a hook in place so that in special cases > >> it > >> >> does not get closed. Conceptually, I like this and started down this > >> >> path > >> >> but the implementation feels wrong. As described in #2, there are no > >> >> hooks > >> >> for handling process group level behavior which is why I've resorted > >> to > >> >> reference counting in the first place. Adding a function to the > >> >> reference > >> >> counter like "keep_socket_open_next_time_ref_count_hits_zero" gives > >> off > >> >> an > >> >> odor of poor design. > >> >> > >> >> Cheers, > >> >> > >> >> Roger > >> >> > >> >> > >> >> On Thu, Sep 9, 2010 at 7:29 AM, Marco Vittorini Orgeas < > >> >> [email protected]> wrote: > >> >> > >> >>> On 09/07/2010 11:01 PM, Roger Hoover wrote: > >> >>> > >> >>>> Hi Marco, > >> >>>> > >> >>>> This looks like a case that I missed. I need to look more closely > >> at > >> >>>> why > >> >>>> it's happening so see if it requires a fundamental change to way > >> >>>> sockets > >> >>>> are > >> >>>> handled. The current implementation doesn't close the socket when > >> all > >> >>>> the > >> >>>> processes are stopped unless a group-level stop command was issued. > >> >>>> The > >> >>>> idea here was to support graceful restarts. If you have a single > >> FCGI > >> >>>> process and want to restart it, should the FCGI socket get torn > >> down > >> >>>> and > >> >>>> recreated? If so, there will be a small amount of time where web > >> >>>> clients > >> >>>> are getting errors while the socket is down. I may have to change > >> it > >> >>>> to > >> >>>> always tear down the socket when the number of processes hit zero > >> >>>> which > >> >>>> would require someone to always run at least two copies if you want > >> >>>> graceful > >> >>>> restart. > >> >>>> > >> >>>> I'll keep you posted on what I find out. > >> >>>> > >> >>>> Thanks, > >> >>>> > >> >>>> Roger > >> >>>> > >> >>> > >> >>> Hi Roger! > >> >>> > >> >>> The idea to recycle sockets , also for allow graceful restarts is > >> >>> valuable. > >> >>> > >> >>> But at the moment it seems that as you said the sockets are not turn > >> >>> down, > >> >>> and just looking at the exception thrown - I've not looking at the > >> code > >> >>> yet > >> >>> sorry - > >> >>> > >> >>> > >> >>> 2010-09-04 10:05:53,366 INFO Creating socket tcp://127.0.0.1:10005 > >> >>>> > >> >>>>> Traceback (most recent call last): > >> >>>>> > >> >>>> > >> >>> File "/usr/lib/python2.6/site-packages/supervisor/process.py", > >> line > >> >>>> > >> >>>>> 694, in __init__ > >> >>>>> raise ValueError('Could not create FastCGI socket %s: %s' % > >> >>>>> (self.socket_manager.config(), e)) > >> >>>>> ValueError: Could not create FastCGI socket tcp://127.0.0.1:10005 > : > >> >>>>> [Errno 98] Address already in use > >> >>>>> > >> >>>> > >> >>> > >> >>> svd is trying to re-create a socket binding it to the same tcp > >> >>> address:port. > >> >>> It's stepping on its toes , because the tcp address is already bind! > >> >>> > >> >>> In order to recycle it- sorry speaking again without looking at the > >> >>> code - > >> >>> it should not try to create a new socket or whatsoever it does that > >> >>> implies > >> >>> to re-create the socket ! > >> >>> > >> >>> Anyway, I've switched to use local (i.e. unix) sockets and reloading > >> >>> occurs without problems. > >> >>> > >> >>> Thank you for your support. > >> >>> > >> >>> -- > >> >>> Marco Vittorini Orgeas > >> >>> > >> >> > >> >> > >> > _______________________________________________ > >> > Supervisor-users mailing list > >> > [email protected] > >> > http://lists.supervisord.org/mailman/listinfo/supervisor-users > >> > > >> > >> > >> > > > > >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
