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).
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
