>>> 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! 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
