> What if you
> cd trunk
> python setup.py install
I did
python setup.py install
and got
NameError: global name 'log' is not defined
The details are below
running install
running bdist_egg
running egg_info
writing requirements to src/supervisor.egg-info/requires.txt
writing src/supervisor.egg-info/PKG-INFO
writing namespace_packages to src/supervisor.egg-info/namespace_packages.txt
writing top-level names to src/supervisor.egg-info/top_level.txt
writing dependency_links to src/supervisor.egg-info/dependency_links.txt
writing entry points to src/supervisor.egg-info/entry_points.txt
Traceback (most recent call last):
File "setup.py", line 89, in ?
entry_points = {
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/install.py",
line 76, in run
self.do_egg_install()
File "/usr/lib/python2.4/site-packages/setuptools/command/install.py",
line 92, in do_egg_install
self.run_command('bdist_egg')
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/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: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
