Should the dependency map come from the "priority" parameters? So no order would be guaranteed for processes with the same priority number but would be guaranteed for different priorities.
On Wed, Sep 9, 2009 at 9:47 AM, Chris McDonough <[email protected]> wrote: > Roger Hoover wrote: > >> In that blog post, it says there was a way to avoid the need for >> staggering. Is there a real use case for this? >> >> If a startdelay parameter is introduced, should there also be a delay >> applied between starting multiple processes in the same process group >> (numprocs > 1)? >> >> What about a global setting telling supervisord to start everything >> serially (don't fork the next process until the previous one is up or failed >> (as determined by it's startsecs command)? >> > > Something like that would be pretty useful. We've always known that > there's some dependency map lurking here obviously. e.g. > > [program:foo] > depends = bar > > ... we've just never got around to doing it. > > - C > > > >> On Wed, Sep 9, 2009 at 8:41 AM, Chris McDonough <[email protected]<mailto: >> [email protected]>> wrote: >> >> Lennart Regebro wrote: >> > Hiya! >> > >> > When starting my zeo-clients I don't want them to all connect at the >> > same time, but stagger it. I found a buildout with a sleep script >> that >> > does this, but it fails when killing the processes during shutdown. >> > (http://rpatterson.net/blog/stagger-supervisord) >> > >> > Is there another way of doing this? :-) >> > >> > I took a quick look at the process.py code and it does not seem >> *very* >> > hairy to implement a startupdelay parameter. Is there any reason not >> > to implement this? If not do you want me to try? >> > >> >> If you've got it in, you sure... >> >> - C >> >> _______________________________________________ >> Supervisor-users mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.supervisord.org/mailman/listinfo/supervisor-users >> >> >> >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
