Wed, 2 Feb 2011 11:52:14 +0100 I think all of that can be handled well by cluster management software like pacemaker [1]. With it's score system you may define priorities with group, order and colocation constraints you can define dependencies. But it is a rather complex job to configure such a setup - and it's a rather complex piece of software that is needed to handle that. I think an init-Script is not exactly the right place to handle cluster failover scenarios. just my 0,02€ Oliver [1] http://clusterlabs.org/wiki/Main Page Am Mittwoch, 2. Februar 2011, um 06:21:25 schrieb Herbert Poetzl: > On Wed, Feb 02, 2011 at 09:37:09AM +0800, Jeff Jansen wrote: > > On Tuesday 01,February,2011 09:30 PM, Daniel Hokka Zakrisson wrote: > > > I still fail to see why you care what order they start in. If you don't > > > have explicit dependencies between them, i.e. you don't use depends, > > > then why does it matter? If you just set the number of parallel starts > > > to whatever number you want, that is the number that will be running > > > at once, all the time. > > > > Because some vservers are more "important" than others. When a primary > > host node crashes and a secondary takes over, I want the important > > vservers to start up before the less important ones. > > > > When I do a kernel upgrade on the hosts and switch the primary and > > secondary, I want the "important" vservers to shutdown last on one side > > and startup first on the other. Then they are down for just a few > > seconds. "Unimportant" vservers shutdown first and startup last. They > > may be down for a couple of minutes. > > > > It's not that the machines "depend" on each other; it's that some are > > much more "mission-critical" than others. I want the mail servers to > > come back first, for example. Vservers running testing or development > > environments, however, should be started last. > > > > I don't want to leave this to alphabetical order by the config > > directory, which is what you get now. I want to say that vserver 'C' > > should start first, vserver 'F' next, and so on. No matter how many I > > start in parallel and no matter how long it takes for any individual > > machine to start, they will come up in this order. > > > > Obviously this isn't a felt need for your situation. Many people > > probably agree with you. When I asked about this on the list (over a > > year ago) only a few folks answered, and those who did said that they > > had worked out their own methods for starting vservers in a certain > > order. I'm proposing a way to 'standardize' this so it doesn't have to > > be "worked out" again. > > I think Daniel might be more inclined to add such a feature > if it would handle the strict order you want to introduce > as a priority instead ... > > i.e. let's assume each guest has a 'priority' entry, which > classifies the guest within an arbitrarily high numeric > range (like 0 - MAX INT), and which is consulted when the > dependancies and the parallel startup have a bunch of other- > wise equal guests to select from > > putting numbers like 100, 200, 300, ... in that priority > entry would then be able to prefer one guest over the other > despite the fact that 10 guests are always started at once > or none of them have any dependancy ... > > HTH, > Herbert > > > But of course, if only a handful of folks actually need this, then it's > > a waste of time and an unnecessary complication to include it. Those of > > us who need it will continue to use our own methods. > > > > Jeff Jansen