Here's another thing I'm seeing with the notify function. It keeps timing out on my slave startup (post-promote-notify and post-start-notify). I'm triggering the start by using the cleanup resources button on the GUI for the slave's resource:
crmd[13681]: 2007/04/05_13:16:47 ERROR: process_lrm_event: LRM operation rsc_pgsql_wal_5556:0_notify_0 (74) Timed Out (timeout=5000ms) Yet I have the timeout value for the notify function bumped up to 120: <op id="1e9ebbb8-a370-4d1e-8815-43d6f0fdcfd6" name="notify" timeout="120" start_delay="0" disabled="false" role=" Started"/> Could it be the default-action-timeout defined for bootstrap options? (see below): <nvpair id="cib-bootstrap-options-default-action-timeout" name="default-action-timeout" value="5s"/> The only other places that a 5s timeout occurs is for an unrelated IP resource, and the meta-data/validate-all/methods functions in my ocf script. Hmm, is the timeout occuring between the crmd and the lrm? Doug On Thu, 2007-04-05 at 12:12 -0400, Doug Knight wrote: > So, should I apply the patch or not? I have my own work-around in > place for the spinning issue (moving set name check prior to node > check). I'm seeing where I need to have more functionality in the > notify function, and fewer calls to crm_master elsewhere. > > I've been using the mgt GUI to create the resource definitions and > start/stop the resources. Is there any more detailed information on > specifically what the various options do (i.e. start, stop, cleanup > resource, work as default), and how their effects differ when a > resource, node, constraint, etc, is selected? The GuiGuide page on the > web site contains only basic information, and the window snapshots > don't match the current GUI. > > Thanks, > Doug > > On Thu, 2007-04-05 at 07:40 -0600, Alan Robertson wrote: > > > Lars Marowsky-Bree wrote: > > > On 2007-04-03T22:05:24, Alan Robertson <[EMAIL PROTECTED]> wrote: > > > > > >>> Yes. I'd avoid needless calls to it though as every call triggers a > > >>> transition - so don't just call it in _every_ monitor operation ;-) > > >> That's a good point. Unfortunately that means the RA has to keep state > > >> somewhere, which is a bit of a pain. > > > > > > That is why I'd suggest to only call it in start or post-notify; calling > > > it in post-notify basically implies it'll be called after every state > > > change. > > > > But, for DRBD for example, the ability to become master can change > > without a heartbeat state change. > > > > This is not at all surprising, nor is it probably uncommon. > > > > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/
_______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
