Anders Quist wrote: > On Wed, 23 Jul 2008 16:11:58 -0400, Chris McDonough <[EMAIL PROTECTED]> > writes: > >>>> 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. > > Oki. > >> 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). > > I suppose 'add' does not care about autostart?
Probably not in its bare form. There might be an argument to the add command that says start after it's been sucessfully added, though. >> "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. > > Sounds reasonable. > > Don't get me wrong; I'm all for simple primitives. It's just that my > view of supervisor is as a tool to ensure that your processes are > according to plan (i.e. config), rather than a framework that lets you > fiddle around with various variations of the plan. > > This is prolly because I see supervisor thru the large-scale > sysadmin's view. From this perspective, any tool that allows > non-permanent changes to the state is suspect, much like any config > file not under version management is suspect. I'm not sure "add"-ing a process is really non-permanent, as you will have changed the persistent state (the config file) to be able to add it, and when supervisord restarts, that state change will be taken into account. I've been asked for this by folks who use a single supervisord to manage processes for multiple customers: when a customer is added, they'd like to be able to add the new customer's processes without shutting their other customers' processes down, and that makes sense to me even in a larger environment. Given that that use case exists, it just seems to make sense to implement "update" in terms of it (which implies a remove step). - C _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
