I think you can do this. svn co http://svn.supervisord.org/supervisor/trunk/ easy_install trunk
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
