> You need to update setuptools.
>
>   easy_install -U setuptools

I did that
and ran easy_install trunk
I got:
Processing trunk
Running setup.py -q bdist_egg --dist-dir
/websites/libraries/supervisord/trunk/egg-dist-tmp-OP-Rex
supervisor 3.0a9 is already the active version in easy-install.pth
Installing echo_supervisord_conf script to /usr/bin
Installing pidproxy script to /usr/bin
Installing supervisorctl script to /usr/bin
Installing supervisord script to /usr/bin

all seems good here.

How can I know I am running on the trunk version of supervisord and not
the 3.0a9 that I had installed before?

Thanks



Installed /usr/lib/python2.4/site-packages/supervisor-3.0a9-py2.4.egg
Processing dependencies for supervisor==3.0a9
Finished processing dependencies for supervisor==3.0a9

>
> If that doesn't work use a different version of Python without this bug.
> Compiling and using your own Python is typically very easy:
>
>   $ wget http://python.org/ftp/python/2.7/Python-2.7.tgz
>   $ tar xvzf Python-2.7.tgz
>   $ cd Python-2.7
>   $ ./configure --with-prefix=/some/directory/Python-2.7
>   $ make
>   $ make install
>   $ wget http://peak.telecommunity.com/dist/ez_setup.py
>   $ /some/directory/Python-2.7/bin/python ez_setup.py
>   $ /some/directory/Python-2.7/bin/easy_install /wherever/trunk/is
>
> - C
>
> On Fri, 2010-09-17 at 13:54 -0400, [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
>>
>
>
>


_______________________________________________
Supervisor-users mailing list
[email protected]
http://lists.supervisord.org/mailman/listinfo/supervisor-users

Reply via email to