Posssible problem with new Bourne shell in Redhat 6.2?

[jf7640]

Hello,

the /bin/sh in RHEL 6 seems to have a different behaviour now than in earlier releases. While previous versions of /bin/sh accepted negative arguments to the built-in "return", this no longer seems to be the case with current /bin/sh in RHEL 6.2:

RHEL 5.3:

[root@rhel5 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

[root@rhel5 ~]# rpm -qf /bin/sh
bash-3.2-24.el5

[root@rhel5 ~]# /bin/sh
sh-3.2# d() { return -1; }
sh-3.2# d
sh-3.2# echo $?
255

RHEL 6.2:

[root@rhel6 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)

[root@rhel6 ~]# rpm -qf /bin/sh
bash-4.1.2-8.el6.x86_64

[root@rhel6 ~]# /bin/sh
sh-4.1# d() { return -1; }
sh-4.1# d
sh: return: -1: Ungültige Option
return: Gebrauch: return [n]
sh-4.1# echo $?
2

The problem is that many shell scripts in Storage Foundation for Linux seem to use 'return -1', e.g. vxadm_syslib.sh. So this new behaviour potentially breaks Storage Foundation scripts.

[root@rhel6 lib]# grep 'return -1' /usr/lib/vxvm/voladm.d/lib/vxadm_syslib.sh | wc -l
13

POSIX norm requires unsigned decimal integer as a return value: http://pubs.opengroup.org/onlinepubs/009695399/utilities/return.html, so the new behaviour seems to be correct. E.g. Solaris:

sol10> /bin/sh
sol10> d() { return -1; }
sol10> d
-1: bad number
sol10> echo $?
1

I tested this with SF 6.0SP1.

A potential fix could be to replace 'return -1' with 'return 255'.

Is there a patch that fixes this?

[TonyGriffiths]

Do you have an example of a SF script that actually breaks in execution ?

Did you have issues with the SF installer on the RHEL6.2 system ?

thanks

tony

[jf7640]

I have issues with installsfha, claiming that it couldn't ping the other cluster member although the other member was resolvable via /etc/hosts and pingable from the command line. But since the installsfha is a deeply nested Perl script I couldn't relate it to a potential 'return -1' issue.

The following errors were discovered on the systems:
CPI ERROR V-9-20-1047 cannot ping rhcluster02
[root@rhcluster01 ~]# ping rhcluster02
PING rhcluster02.test.baltic-online.de (10.1.0.141) 56(84) bytes of data.
64 bytes from rhcluster02.test.baltic-online.de (10.1.0.141): icmp_seq=1 ttl=64 time=0.173 ms

And I think with SF 6.0 I had an issue with vxdisksetup but I don't remember exactly and regrettably cannot reproduce it anymore with 6.0SP1.

[jf7640]

Sorry, this should read 6.0RP1 not SP1.

[jf7640]

vxdiskadm fails because of 'return -1' when trying to suppress the only path to a device:

# Only path to disk_0 is /dev/sda
[root@rhel6 ~]# vxdisk path | grep disk_0
sda                         disk_0               -            -            ENABLED
[root@rhel6 ~]# vxdiskadm
# Menu 17: Prevent multipathing/Suppress devices from VxVM's view
# Menu 2: Suppress a path from VxVM's view
...
Enter a pathname or pattern : [,all,list,list-exclude,q,?] sda

  VxVM  INFO V-5-2-1221 The following paths will be excluded from VxVM as a result of this operation:

        sda            


Continue operation? [y,n,q,?] (default: y) y
/usr/lib/vxvm/voladm.d/lib/vxadm_lib.sh: line 2747: return: -1: invalid option
return: usage: return [n]
# The device is still visible
[root@rhel6 ~]# vxdisk path | grep disk_0
sda                         disk_0               -            -            ENABLED

Kind regards,

Jochen

[jf7640]

The problem with the installsfha (i.e. the ping) turned out to be due to a wrong locale setting. I had LANG="de_DE.UTF-8". When I set LANG="en_US.UTF-8" the problem disappeared.

[TonyGriffiths]

We are looking into the shell issue you highlighted in this post.

thanks