[Supervisor-users] Online config reload patch, take 1

Roger Hoover roger.hoover at gmail.com
Tue Nov 25 18:03:56 EST 2008


Thanks, guys.  This is great news.

I'd also appreciate a new release to take advantage of these features.

Roger

On Sun, Nov 23, 2008 at 11:37 AM, Chris McDonough <chrism at plope.com> wrote:

> Hi Anders,
>
> This work is merged to the trunk now.  Thank you.  I added some
> error-handling
> behavior in "reread", but it went in otherwise unchanged.  I need to huddle
> with
> Mike a bit to see if we need to make any changes, but hopefully we can get
> a new
> release out with these changes as well as Siddhant's work for GSOC
> ("foreground
> mode", and tab completion in supervisorctl).
>
> - C
>
> Anders Quist wrote:
> > I finally got the time to finish the config reloading patch. Apart
> > from add/remove, there is now:
> >
> >   reread          Reload the daemon's configuration files
> >   update          Reload config and add/remove as necessary
> >   avail           Display all configured processes
> >
> > In supervisorctl:
> >
> >   supervisor> status
> >   bar                              RUNNING    pid 14864, uptime 18:03:42
> >   baz                              RUNNING    pid 23260, uptime 0:10:16
> >   foo                              RUNNING    pid 14866, uptime 18:03:42
> >   gazonk                           RUNNING    pid 23261, uptime 0:10:16
> >   supervisor> avail
> >   bar                              in use    auto      999:999
> >   baz                              in use    auto      999:999
> >   foo                              in use    auto      999:999
> >   gazonk                           in use    auto      999:999
> >   quux                             avail     auto      999:999
> >
> > Now we add this to our conf:
> >
> >   [group:zegroup]
> >   programs=baz,gazonk
> >
> > Then we reread conf:
> >
> >   supervisor> reread
> >   baz: disappeared
> >   gazonk: disappeared
> >   quux: available
> >   zegroup: available
> >   supervisor> avail
> >   bar                              in use    auto      999:999
> >   foo                              in use    auto      999:999
> >   quux                             avail     auto      999:999
> >   zegroup:baz                      avail     auto      999:999
> >   zegroup:gazonk                   avail     auto      999:999
> >   supervisor> status
> >   bar                              RUNNING    pid 14864, uptime 18:04:18
> >   baz                              RUNNING    pid 23260, uptime 0:10:52
> >   foo                              RUNNING    pid 14866, uptime 18:04:18
> >   gazonk                           RUNNING    pid 23261, uptime 0:10:52
> >
> > The magic make-it-so command:
> >
> >   supervisor> update
> >   baz: stopped
> >   baz: removed process group
> >   gazonk: stopped
> >   gazonk: removed process group
> >   zegroup: added process group
> >   quux: added process group
> >   supervisor> status
> >   bar                              RUNNING    pid 14864, uptime 18:04:43
> >   foo                              RUNNING    pid 14866, uptime 18:04:43
> >   quux                             RUNNING    pid 23561, uptime 0:00:02
> >   zegroup:baz                      RUNNING    pid 23559, uptime 0:00:02
> >   zegroup:gazonk                   RUNNING    pid 23560, uptime 0:00:02
> >   supervisor> avail
> >   bar                              in use    auto      999:999
> >   foo                              in use    auto      999:999
> >   quux                             in use    auto      999:999
> >   zegroup:baz                      in use    auto      999:999
> >   zegroup:gazonk                   in use    auto      999:999
> >
> > Of course, I could have issed reread and used add to add e.g. only
> > quux and later done update for the rest.
> >
> > There are various points to this implementation:
> >
> >  * update is implemented in supervisorctl and thus not directly
> >    available in the RPC interface.
> >
> >  * update does removed, changed, added, in that order. In theory, a
> >    process that doesn't handle being started more than once (e.g. lock
> >    file), may run into trouble (I think).
> >
> >  * There are numerous variations of adding/changing/removing programs
> >    and programs moving into and out of groups. Thus, there may well be
> >    scenarios in which the above tools behaves unexpectedly.
> >
> >  * In the current implementation, options' process_group_configs and
> >    supervisord's process_groups[...].config is the same object. This
> >    seems to be ok in this implementation, but it seems only a matter
> >    of time until someone is bitten by diff not reporting changes.
> >
> >  * Add starts any services which have autostart set. However, the user
> >    is not told in supervisorctl, which may result in surprises.
> >
> >  * reread is a silly name. Suggestions welcome.
> > --
> > Anders Qvist, Open End AB
> > Tel: +46 31 7490887
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Supervisor-users mailing list
> > Supervisor-users at lists.supervisord.org
> > http://lists.supervisord.org/mailman/listinfo/supervisor-users
>
> _______________________________________________
> Supervisor-users mailing list
> Supervisor-users at lists.supervisord.org
> http://lists.supervisord.org/mailman/listinfo/supervisor-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.supervisord.org/pipermail/supervisor-users/attachments/20081125/d586465c/attachment.htm 


More information about the Supervisor-users mailing list