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