On Tue, Aug 28, 2007 at 01:43:58PM +0100, Ben Clewett wrote: > > > Hi again Dejan, > > Dejan Muhamedagic wrote: > > On Fri, Aug 24, 2007 at 09:55:06AM +0100, Ben Clewett wrote: > >> > >> Ben Clewett wrote: > >>> > >>> Hi Dejan, > >>> > >>> Got it! It's one of the options the GUI can't see, so I would never > >>> have got there. (I am the GUI generation :) > >>> > >>> <nvpair id="cib-bootstrap-options-default-action-timeout" > >>> name="default-action-timeout" value="40s"/> > >> Just to correct my self, the option IS in the GUI called 'Transition > >> Timeout'.... > > > > Is it? > > Yes. If I alter "default-action-timeout" in the XML, "Transition > Timeout" alters in the GUI. > > > But that's a very different thing AFAIK: it's the period > > within which a transition should finish. A transition is a set of > > operations carried out in order to reach certain state, it > > usually entails several operations. An action timeout is what is > > used for an operation (such as monitor/start/stop). > > I understand. Maybe there is a bug in the GUI? > > > > I think that you should set the "default-action-timeout" to what > > fits the majority of your actions. Then, you can override it for > > any specific operations within the operation definition, as > > somebody already suggested before. That way your cluster will > > be better documented, easier to maintain, and have better > > timeouts defined. On the minus side, the configuration is going > > to be slightly bigger. > > I very much agree. I would prefer a nice tight default, which I could > let out for the slower services. > > > > On timeouts: leave a good safety margin, try to foresee all > > situations in which you don't want the cluster disturbed while > > keeping your failover times within the defined policy. > > Can you please send me a link to this documentation? As in, what > vaiables are avaiable, and what they effect. I am having a great deal > of trouble finding out this sort of detail, hence postings such as this > one to these news groups.
The best documentation is the dtd: http://www.linux-ha.org/ClusterResourceManager/DTD1.0/Annotated or, actually: http://hg.linux-ha.org/dev/file/tip/crm/crm-1.0.dtd > Kind regards, > > Ben > > > >> Sometimes it's hard to see the wood from the trees! > > > > Not this time, it doesn't seem so. > > > >> Ben > >> > >>> Setting this timeout to 40 seconds allows my disk to mount, and > linux-ha > >>> is running perfectly. > >>> > >>> Many thanks "Dr House" of the linux-ha, and other very useful > >>> suggestions from other users. > >>> > >>> Ben > >>> > >>> ------------- > >>> > >>> PS, > >>> > >>> Dare I ask, but why all the configurable timeouts in the Filesystem > CRM > >>> if they are not used for anything? > >>> > >>> > >>> > >>> > >>> Dejan Muhamedagic wrote: > >>>> On Thu, Aug 23, 2007 at 05:25:44PM +0100, Ben Clewett wrote: > >>>>> Hi, > >>>>> > >>>>> Probably me misunderstanding you :) > >>>>> > >>>>> (This is probably more for the linux-ha mailing list now, but it may > >>>>> be of interest here...) > >>>>> > >>>>> There are various parameters in the Filesystem ocf: > >>>>> > >>>>> <actions> > >>>>> <action name="start" timeout="60" /> > >>>>> <action name="stop" timeout="60" /> > >>>>> <action name="notify" timeout="60" /> > >>>>> <action name="monitor" depth="0" timeout="40" interval="20" > >>>>> start-delay="10" /> > >>>>> <action name="validate-all" timeout="5" /> > >>>>> <action name="meta-data" timeout="5" /> > >>>>> </actions> > >>>>> > >>>>> But this is odd. The start timeout shows as 60s. Yet linux-ha > >>>>> killed the mount operation after 10 seconds, therefore making drbd > >>>>> permanently stale. Is this another bug? > >>>> Probably not. Or, let's say that it's probably a documentation > >>>> bug. Actually, I'm also not sure why, but what is apparently > >>>> used as the timeout is the default-action-timeout from the > >>>> cluster_property_set. > >>>> > >>>>> This was really my reason for mailing, I wanted to see if there were > >>>>> any ocf experts out there... As well as to report a possible bug. > >>>> Well, on the one hand what you encountered was definitely a > >>>> surprise, perhaps the default timeout should be raised. On the > >>>> other hand, you should normally try to run all resources, or at > >>>> least those about which you are not sure how they are going to > >>>> behave and I'd expect a 3TB filesystem to be in that category, by > >>>> hand before starting them by the cluster. > >>>> > >>>>> I am making better progress by upping all these values. If I find > >>>>> anything of significant interest, I'll report back :) > >>>>> > >>>>> Ben > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> matilda matilda wrote: > >>>>>>>>> Ben Clewett <[EMAIL PROTECTED]> 23.08.2007 17:38 >>> > >>>>>>> The reason for this email is just to note to the group that a > large > >>>>>>> file system under drbd mounted by the latest linux-ha will cause a > >>>>>>> problem which can only be sorted by a complete re-boot. > >>>>>>> > >>>>>>> I hope this will be useful, and somebody may decide it's a bug > >>>>>>> worth investigation... > >>>>>> Hi Ben, > >>>>>> > >>>>>> I'm sure you misunderstood me, but probably I misunderstand you. :-) > >>>>>> As I said in my first answer: You HAVE to increase the timeout value > >>>>>> for the start operation of your Resource Agent. As you said in your > >>>>>> initial mail, your RA times out before the big filesystem CAN be > >>>>>> mounted because of its size. You CAN set a timeout for every action > >>>>>> of every resource overwriting the default action timeout. > >>>>>> > >>>>>> So, really, enhance the timeout value to a real comfortable value. > >>>>>> It's better to make it too big than too small. > >>>>>> If you already made this forget this mail. :-) > >>>>>> > >>>>>> Best regards > >>>>>> Andreas > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Linux-HA mailing list > >>>>>> [email protected] > >>>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >>>>>> See also: http://linux-ha.org/ReportingProblems > >>>>>> > >>>>> > ************************************************************************* > >>>>> > >>>>> This e-mail is confidential and may be legally privileged. It is > >>>>> intended > >>>>> solely for the use of the individual(s) to whom it is addressed. Any > >>>>> content in this message is not necessarily a view or statement > from Road > >>>>> Tech Computer Systems Limited but is that of the individual > sender. If > >>>>> you are not the intended recipient, be advised that you have received > >>>>> this e-mail in error and that any use, dissemination, forwarding, > >>>>> printing, or copying of this e-mail is strictly prohibited. We use > >>>>> reasonable endeavours to virus scan all e-mails leaving the > company but > >>>>> no warranty is given that this e-mail and any attachments are virus > >>>>> free. > >>>>> You should undertake your own virus checking. The right to monitor > >>>>> e-mail > >>>>> communications through our networks is reserved by us > >>>>> > >>>>> Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > >>>>> Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > >>>>> Registered in England No: 02017435, Registered Address: Charter > >>>>> Court, Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > >>>>> > ************************************************************************* > >>>>> > >>>>> _______________________________________________ > >>>>> Linux-HA mailing list > >>>>> [email protected] > >>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >>>>> See also: http://linux-ha.org/ReportingProblems > >>>> _______________________________________________ > >>>> Linux-HA mailing list > >>>> [email protected] > >>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >>>> See also: http://linux-ha.org/ReportingProblems > >>>> > >>> > >>> > ************************************************************************* > >>> This e-mail is confidential and may be legally privileged. It is > intended > >>> solely for the use of the individual(s) to whom it is addressed. Any > >>> content in this message is not necessarily a view or statement from > Road > >>> Tech Computer Systems Limited but is that of the individual sender. If > >>> you are not the intended recipient, be advised that you have received > >>> this e-mail in error and that any use, dissemination, forwarding, > >>> printing, or copying of this e-mail is strictly prohibited. We use > >>> reasonable endeavours to virus scan all e-mails leaving the company but > >>> no warranty is given that this e-mail and any attachments are virus > free. > >>> You should undertake your own virus checking. The right to monitor > e-mail > >>> communications through our networks is reserved by us > >>> > >>> Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > >>> Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > >>> Registered in England No: 02017435, Registered Address: Charter Court, > >>> Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > >>> > ************************************************************************* > >>> _______________________________________________ > >>> Linux-HA mailing list > >>> [email protected] > >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >>> See also: http://linux-ha.org/ReportingProblems > >>> > >> > >> > ************************************************************************* > >> This e-mail is confidential and may be legally privileged. It is > intended > >> solely for the use of the individual(s) to whom it is addressed. Any > >> content in this message is not necessarily a view or statement from Road > >> Tech Computer Systems Limited but is that of the individual sender. If > >> you are not the intended recipient, be advised that you have received > >> this e-mail in error and that any use, dissemination, forwarding, > >> printing, or copying of this e-mail is strictly prohibited. We use > >> reasonable endeavours to virus scan all e-mails leaving the company but > >> no warranty is given that this e-mail and any attachments are virus > free. > >> You should undertake your own virus checking. The right to monitor > e-mail > >> communications through our networks is reserved by us > >> > >> Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > >> Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > >> Registered in England No: 02017435, Registered Address: Charter Court, > >> Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > >> > ************************************************************************* > >> _______________________________________________ > >> Linux-HA mailing list > >> [email protected] > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >> See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > > > ************************************************************************* > This e-mail is confidential and may be legally privileged. It is intended > solely for the use of the individual(s) to whom it is addressed. Any > content in this message is not necessarily a view or statement from Road > Tech Computer Systems Limited but is that of the individual sender. If > you are not the intended recipient, be advised that you have received > this e-mail in error and that any use, dissemination, forwarding, > printing, or copying of this e-mail is strictly prohibited. We use > reasonable endeavours to virus scan all e-mails leaving the company but > no warranty is given that this e-mail and any attachments are virus free. > You should undertake your own virus checking. The right to monitor e-mail > communications through our networks is reserved by us > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > Registered in England No: 02017435, Registered Address: Charter Court, > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > ************************************************************************* > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
