Running heartbeat 2.0.7 as provided by Debian 4.0 official packages.
Two nodes (cmphoto2 and cmphoto3), running heartbeat in the 'old haresource' mode rather than with crm, as I couldn't get my head wrapped around the whole XML configuration. My haresource file only has one uncommented line: cmphoto2 drbddisk::photo_archive 192.168.4.127/24/vnews Filesystem::/dev/drbd0::/mnt/shared_archive::jfs winbind samba Under an orderly shutdown (i.e. /etc/init.d/heartbeat stop, or shutdown -h now, or hitting the power button [which goes via ACPI to initiate a controlled shutdown]), cmphoto3 properly takes over all resources from cmphoto2. When pulling power from cmphoto2, cmphoto3 dies when starting Filesystem, as the filesystem on /dev/drbd0 is dirty and requires a replay of the journal. Since Filesystem didn't start, it bails out of all resources. Repowering cmphoto2 also leaves everything in shambles, as it will properly think it needs to take over, but since the Filesystem is dirty and won't mount, it also bails out of all resources. I found that if I edit the file /usr/lib/ocf/resource.d/heartbeat/Filesystem line 354 (where it decides which filesystem types don't need to be fscked), and REMOVE the entry for jfs then the cluster responds as I wish to 'pull the power from cmphoto2' events. If I understand the coding correctly, this means that it is running a fsck on this filesystem every time it is started, however my understanding is that with jfs this shouldn't take an inordinate amount of time. My questions are: 1.) Is forcing a fsck at every start of the Filesystem resource the best way to solve this problem? 2.) Is there a way to do this that doesn't involve editing the Filesystem script, but rather some setting in one of the configuration files (so that when Debian gets around to upgrading to 2.0.8 or whatever, I don't have to reapply my fix by hand [or worse yet, forget to do so and leave my cluster vulnerable to 'cmphoto2 goes away unexpectedly'])? Thanks in advance to any advice! _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
