[Pacemaker] unmanaged resource - cluster influence - ocf:heartbeat:Filesystem

[Bauer, Stefan (IZLBW Extern)]

Hello,

I'm using ocf:heartbeat:Filesystem to mount a cifs share. Additionally I enabled OCF_CHECK_LEVEL 20 to read/write from the cifs-share during monitor operation:

If I block the connection to the cifs-server with iptables, the monitor operation times out. After several tries, a restart of the resource is initiated. The resource fails to stop (another timeout) so it ends up in a INFINITY and the resource is unmanaged:

Jun 17 13:49:21 node1 lrmd: [15029]: WARN: p_cifs_pictures:monitor process (PID 18444) timed out (try 1).  Killing with signal SIGTERM (15).
Jun 17 13:49:21 node1 lrmd: [15029]: WARN: operation monitor[43] on p_cifs_pictures for client 15032: pid 18444 timed out

Jun 17 13:49:21 node1 Filesystem2[18750]: INFO: Running stop for //cifs/share/pictures on /srv/cifs/pictures
Jun 17 13:49:21 node1 Filesystem2[18750]: INFO: Trying to unmount /srv/cifs/pictures
Jun 17 13:49:41 node1 lrmd: [15029]: WARN: p_cifs_pictures:stop process (PID 18750) timed out (try 1).  Killing with signal SIGTERM (15).

Jun 17 13:49:41 node1 crmd: [15032]: WARN: status_from_rc: Action 5 (p_cifs_pictures_stop_0) on node1 failed (target: 0 vs. rc: -2): Error
Jun 17 13:49:41 node1 crmd: [15032]: WARN: update_failcount: Updating failcount for p_cifs_pictures on node1 after failed stop: rc=-2 (update=INFINITY, time=1403005781)
Jun 17 13:49:41 node1 pengine: [15031]: WARN: common_apply_stickiness: Forcing p_cifs_pictures away from node1 after 1000000 failures (max=1000000)

So far so bad. How can I avoid a timeout during the recover? I mean what is the read/write check all about if it leaves the resource unmanaged at the end?

I fully understand, that if the resource is not securely shut down and stonith is not active, it should be unmanaged.

Thank you.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140618/c5994b21/attachment-0002.html>