On Mon, Feb 04, 2013 at 08:35:21AM +0100, Ulrich Windl wrote: > >>> Dejan Muhamedagic <[email protected]> schrieb am 01.02.2013 um 13:01 in > Nachricht <[email protected]>: > > On Fri, Feb 01, 2013 at 09:47:21AM +0100, Ulrich Windl wrote: > > > >>> Dejan Muhamedagic <[email protected]> schrieb am 01.02.2013 um > > > >>> 08:53 in > > > Nachricht <[email protected]>: > > > > Hi, > > > > > > > > On Fri, Feb 01, 2013 at 08:24:46AM +0100, Ulrich Windl wrote: > > > > > Hi! > > > > > > > > > > While trying to develop an improved exportfs RA that can export one > > > > filesystem to a list of names (instead of just one name), I found an > > error: > > > > > > > > > > exportfs is returning exit code 0 even if the filesystem could not be > > > > exported, like in > > > > > > > > > > > h02:~ # exportfs h012:/mnt; echo $? # h012 does not exist > > > > > > exportfs: Failed to resolve h012 > > > > > > 0 > > > > > > > > > > Accordingly the start operation for the exportfs alway reports > > > > > success, > > > > even if the operation failed! That's due to > > > > > > > > > > [...] > > > > > > ocf_run exportfs -v ${OPTIONS} > > > > ${OCF_RESKEY_clientspec}:${OCF_RESKEY_directory} || exit > > > > $OCF_ERR_GENERIC > > > > > > > > > > > > > > > > > > # Restore the rmtab to ensure smooth NFS-over-TCP failover > > > > > > > > > > > > restore_rmtab > > > > > > > > > > > > ocf_log info "File system exported" > > > > > > return $OCF_SUCCESS > > > > > [...] > > > > > > > > > > However the monitor operation does the correct thing, thus reporting > > > > > an > > > > error (rc==7). > > > > > > > > We could insert the monitor operation after the call to exportfs. > > > > Would there be any timing issues? I guess not. > > > > > > > > Thanks, > > > > > > > > Dejan > > > > > > Hi! > > > > > > I'd fix the root of the problem: exportfs is unreliable! > > > > That also, but it is probably going to take some time. Did you > > open a bugzilla somewhere? > > Hi, > > yes I did, but it didn't really help 8-(
Do you want to share a link? Thanks, Dejan > Regards, > Ulrich > > > > > > Thanks, > > > > Dejan > > > > > Regards, > > > Ulrich > > > > > > > > > > > > > > > > > > This combination leads to the message of ocf-tester: > > > > > * rc=1: Monitoring an active resource should return 0 > > > > > > > > > > (The tester thinks the resource was started when it was not) > > > > > > > > > > I had reported this for SLES10 SP2 to support in November, but after > > > > > a > > long > > > > time of waiting and repeating the same facts over and over, support > > > > told > > me > > > > it's "working as designed"; lvscan and lvcreate would be similar. > > > > > > > > > > A quick test showed that this is actually not true vor lvcreate: > > > > > # lvcreate -n bar -L40G foobar; echo $? > > > > > Volume group "foobar" not found > > > > > 5 > > > > > # lvcreate -n foo -L1T sys; echo $? > > > > > Volume group "sys" has insufficient free space (1855 extents): > > > > > 32768 > > > > required. > > > > > 5 > > > > > > > > > > I got the impression that my support is just unwilling to fix the > > > > > rather > > > > trivial problem. My exportfs comes from nfs-kernel-server-1.2.3-18.23.1. > > > > > > > > > > Getting the exportfs sources, it took me two minutes to find out that > > > > exportfs uses variable export_errno to define the exit code, and that > > > > variable is nowhere set. The worker routine exportfs() does return > > > > nothing > > at > > > > all. What a design! > > > > > > > > > > Here's an example from an old HP-UX system that didn't get any > > > > > updates for > > > > > > three years: > > > > > > > > > > # exportfs nohost:/mnt; echo $? > > > > > exportfs: no entry for nohost:/mnt in /etc/dfs/dfstab > > > > > 1 > > > > > > > > > > Here it works! > > > > > > > > > > I wonder why some Linux people are so ignorant occasionally... > > > > > > > > > > Regards, > > > > > Ulrich > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > 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
