On 02/01/2013 08:53 AM, Dejan Muhamedagic wrote:
> 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
>
>> 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
RHEL6 shows the same behavior as SLES:
[root@rhel6 sbin]# exportfs h012:/mnt; echo $?
exportfs: Failed to resolve h012
0
>> 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
