"Down by default" makes sense to me and will be a great feature. I think that having it will require all services to have a 'down' script that defines how to make sure that a service is actually down.
I wonder if this will help address a common situation for me where I install a package and realize that at the end of the installation the daemon is started using upstart or sysv. At that point, to 'supervise' the app, I first have to stop the current daemon and then start it up using runit or another process manager. Otherwise I end up with two copies of the app running, with only one of them being supervised. John Albietz m: 516-592-2372 e: inthecloud...@gmail.com l'in: www.linkedin.com/in/inthecloud247 On Tue, Jan 6, 2015 at 10:20 AM, Laurent Bercot <ska-supervis...@skarnet.org > wrote: > On 06/01/2015 18:46, Avery Payne wrote: > >> 1. A service can ask another service to start. >> 2. A service can only signal itself to go down. It can never ask another >> service to go down. >> 3. A service can only mark itself with a ./down file. It can never mark >> another service with a ./down file. >> >> That's it. Numbers 2 and 3 are the only times I would go against what you >> are saying. >> > > So does number 1. > When you ask another service to start, you change the global state. If > it is done automatically by any tool or service, this means the global > state changes without the admin having requested it. This is trying to > be smarter than the user, which is almost always a bad thing. > > Number 2 is in the same boat. If the admin wants you to be up, > then you can't just quit and decide that you will be down. You can't > change the global state behind the admin's back. > > Number 3 is different. It doesn't change the global state - unless there's > a serious incident. But it breaks resiliency against that incident: it > kills the guarantee the supervision tree offers you. > > I firmly believe that a tool, no matter what it is, should do what the > user wants, even if it's wrong or can't possibly work. If you cannot do > what the user wants, don't try to be smart; yell at the user, spam the > logs if necessary, and fail. But don't do anything the user has not > explicitly told you to do. > > Maybe a dependency manager needs to be smarter than that. In which case > I would call it a "global state manager". There would be the "current > state", which starts at "everything down" when the machine boots, and > the "wanted state", which starts at "everything up"; as long as those > states are not matched, the global state manager is running, implementing > retry policies and such, and may change the global state at any time, > bringing individual services up and down as it sees fit, with the > ultimate goal of matching the global current state with the global wanted > state. It could do stuff like exponential backoff so failing services > would not be "wanted up" all the time; but it would never, ever change > the global wanted state without an order to do so from the admin. > > If you want a dependency manager with online properties, I think this > is the way to do it. > > -- > Laurent > >