Hi Digimer, hi Lazlo, sorry, for intruding your thread but this is something that I am also interested in and which I haven't fully fathomed yet. > -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Digimer > Sent: Thursday, July 28, 2011 2:51 AM > To: linux clustering > Subject: Re: service startup order > > Parallel services will be started simultaneously. Services > configured as > service trees will start in the order that they are defined > (and stopped > in reverse order). > > This covers the start order well: > - https://fedorahosted.org/cluster/wiki/ResourceTrees > The referred to wiki article only seems to treat starting/stopping order and hierarchy (parent-child vs. sibling) of resources within one service aka resource group. That sounds pretty clear. But what about ordering and possible dependencies between separate services? You mentioned service trees. You didn't actually mean resource trees? If however your wording was deliberate (what I assume) I wonder if one can nest service tag blocks as one can nest resource tags within a single service block to express dependencies or hierarchy and hence starting order between and of services? Because all the sample configuration snippets I have seen so far in various docs lack such nesting of services. The reason that interests me is because I have such a case where a customer requires such a dependency between two distinct services that during normal operation (i.e. no node has left the cluster) are hosted on different nodes. I told them, from what I have perceived of HA clustering and RHCS in particular so far, that if they wish to express such an interdependency that they would have to put all resources which are now split up in two services, in a nested manner that would map the intended hierarchy, in a single service. Because they insisted on their layout I searched a little and discovered the, in the official RHCS Admin doc not mentioned, service tag attributes "depend" and "depend_mode". However, their usage at first seemed pretty useless because the clusterware seemed to completely ignore them and start/stop services in sometimes unpredictable ways and even restarted them at random. Until I, more by accident, discovered that additionally the "rm" tag's attribute "central_processing" needed to be defined and assigned to "1" or "true" for this feature to work approximately. I say apprimately here because we still have issues with this cluster that require futher testing. I hardly dare mentioning, that unfortunately this system already went into production, now of course lacking any HA, why we had to defer further testing. Regards Ralph -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
