Anders Quist wrote: > On Wed, 23 Jul 2008 10:52:25 -0400, Chris McDonough <[EMAIL PROTECTED]> > writes: > >> Anders Quist wrote: >>> On Fri, 18 Jul 2008 12:15:04 -0400, Chris McDonough <[EMAIL PROTECTED]> >>> writes: >>> >>>>>> This feature (reload a process) is much-asked for and would be very >>>>>> useful. I can't speak for the other developers on the list, but I've >>>>>> personally more or less been waiting to have that particular itch >>>>>> myself or find someone who has that itch to fund the feature. >>>>>> Twiddler is a good solution in the meantime, as Roger said, however >>>>> Will you consider a patch if we submit one? >>>> Of course! FTR, we're a bit sticky on tests, though. We don't really >>>> accept patches that break the current test suite, or which add new >>>> features that aren't tested. >>> Some design issues: >>> >>> - How to decide if a proccess has had its configuration changed? I >>> would prefer ProcessConfig objects to grow an __eq__ method, but it >>> would be a hassle to know which attributes to look at, unless one >>> does dir(self). >> What would __eq__ compare it against? > > The old config's ProcessConfig.
Ah. Well, sure. >> For the record, rather than going for the "do what I mean" of >> comparing running process configs against the config file right >> away, a first step towards this goal would be to add the following >> commands to supervisorctl and accompanying backend handlers: > > Heh. I started in the other end. The code to reload the config and > handle that is already written. So is figuring out what is added and > removed. Finding the processes that changed is easy except that the > list of ProcessConfig members is so long. > >> add -- >> >> Add a process to the running config from a section in the config file. >> You may not add a program that is already in the running configuration. >> >> remove -- >> >> Remove a process from the running config. The process must first >> be stopped. >> >> That would be useful by itself. If you knew that you had just change the >> frobnozz program config, you would issue: >> >> stop frobnozz >> remove frobnozz >> add frobnozz > > What does it mean to remove a process from the running config? I don't > really see why you would need more than "update frobnozz" which would > update that process or group to the state named in the config on disk? Removing a process from the running config would mean that it wont show up in the process list anymore. Adding a process would mean that it would read a config section from disk, and add it to the process table. This is something that people also want (adding a new process to a running supervisord). "update frobnozz" would obviously also need to stop any existing frobnozz before it could start another frobnozz. As such, it should be implemented in terms of "stop", then "remove", then "add" IMO. - C _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
