Bug 1088032 - Linux/Unix shell scripts attempt to use readlink even if it isn't installed/exist causing "readlink: not found" to be displayed
Summary: Linux/Unix shell scripts attempt to use readlink even if it isn't installed/e...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Launch Scripts
Version: JON 3.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ER04
: JON 3.3.0
Assignee: John Mazzitelli
QA Contact: Sunil Kondkar
URL:
Whiteboard:
Depends On: RHQ-1752
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-15 21:04 UTC by Larry O'Leary
Modified: 2018-12-05 18:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When executing launcher scripts such as rhqctl, the readlink command is used to resolve a scripts' real location in case it is a symbolic link. Users running operating systems where readlink was not installed by default (such as Solaris), or not present on the path, experienced a message similar to: "./rhqctl: readlink: not found". The fix to rhqctl now shows a warning message if readlink does not exist, which allows users to install the appropriate packages and continue with the operation.
Clone Of:
Environment:
Last Closed: 2014-12-11 14:02:07 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 534611 None None None Never
Red Hat Bugzilla 535012 None None None Never
Red Hat Bugzilla 535784 None None None Never
Red Hat Knowledge Base (Solution) 791183 None None None Never
Red Hat Bugzilla 803039 None None None Never

Internal Links: 534611 535012 535784 803039

Description Larry O'Leary 2014-04-15 21:04:19 UTC
Description of problem:
When executing launcher scripts such as rhqctl, the readlink command is used to resolve the scripts real location in case it is a symbolic link. However, if readlink is not installed or on the path, some shells will display the message:

./rhqctl: readlink: not found

Version-Release number of selected component (if applicable):
3.2.0.GA

How reproducible:
Always

Steps to Reproduce:
1. Using Bourne Shell on Solaris 10, execute ./rhqctl install

Actual results:
rhqctl output reveals:

./rhqctl: readlink: not found
./rhq-storage-installer.sh: readlink: not found
./rhq-server.sh: readlink: not found
./rhq-installer.sh: readlink: not found


Expected results:
If readlink is really required, the script should abort with an appropriate error message. Otherwise, the message should be suppressed or a meaningful warning displayed.

Additional info:
Before executing this GNU utility that may not be installed on the target machine, the scripts should check for its existence. This can be done using something like:

type readlink >/dev/null 2>&1
if [ $? -ne 0 ]; then
    echo >&2 'WARNING: The readlink command is not available on this platform.'
    echo >&2 '         If this script was launched from a symbolic link, it may '
    echo >&2 '         fail to properly resolve its home directory.'
fi

Comment 1 Larry O'Leary 2014-04-15 21:46:06 UTC
Based on a suggestion from Mazz in bug 535012 I was able to use the following shell commands in place of readlink:

resolvelink() { 
    if [ ! -L "$1" ]; then
        echo "$1"
    else 
        _ls="`ls -ld -- "$1"`"
        _link="`expr "${_ls}" : '.*-> \(.*\)$'"
        cd "`dirname "$1"`"
        resolvelink "${_link}"
    fi
}


This seems to work fine in the original Bourne Shell (/bin/sh -- not to be confused by the /bin/sh -> /bin/bash link used on modern Linux distributions)

Comment 2 Jay Shaughnessy 2014-09-08 15:49:10 UTC
I believe this was fixed upstream by Bug Bug 1083557.  Larry, do you agree?  If so, please mark as ON_QA for ER02.  Otherwise, please explain what makes this different (enough so that mazz can work on this :).

Comment 3 Larry O'Leary 2014-09-09 00:06:59 UTC
This has not yet been fixed from what I can tell -- unless of course there is a commit somewhere I am missing.

Bug 1083557 identified an issue in how a sub-shell was being invoked. In Bash, a sub-shell is invoked using $() and supports a cleaner syntax and better escaping. In POSIX the $() sub-shell isn't supported. So the fix in bug 1083557 was to use `` instead of $().

This bug on the other hand deals with the fact that on operating systems -- such as Solaris which we fully support out-of-the-box -- readlink is not available by default. In those cases, rhqctl and our other internal scripts fail due to the inability to determine if dirname is a symbolic link or a physical path.

As indicated in comment 1 above, the fix for this issue is to introduce a 'fall-back' method in cases readlink is not installed/available. This was originally proposed by Mazz in upstream bug 535012 but never implemented. However, in May of this year it appears you closed out the upstream bug without any fix being applied. 

From what I can tell, the following scripts require readlink:

    bin/internal/rhq-server.sh
    bin/internal/rhq-storage-installer.sh
    bin/internal/rhq-installer.sh
    bin/rhq-data-migration.sh
    bin/rhq-encode-password.sh
    bin/rhqctl

Comment 4 Jay Shaughnessy 2014-09-09 00:37:56 UTC
OK, thanks for the explanation, I'll assign to mazz for further consideration.

Comment 5 John Mazzitelli 2014-09-09 18:39:01 UTC
The error has been suppressed in recent versions, but I will also a warning message be displayed.

> type readlink >/dev/null 2>&1
> if [ $? -ne 0 ]; then
>     echo >&2 'WARNING: The readlink command is not available on this
> platform.'
>     echo >&2 '         If this script was launched from a symbolic link, it
> may '
>     echo >&2 '         fail to properly resolve its home directory.'
> fi

That will be the message that is output.

master commit:

commit 3fad5e975619fde2a6719616e823c90c143a3e8a
Author: John Mazzitelli <mazz@redhat.com>
Date:   Tue Sep 9 14:38:31 2014 -0400

    BZ 1088032 - show a warning message if readlink doesn't exist.

Comment 6 Jay Shaughnessy 2014-09-09 20:33:53 UTC
Release/jon3.3.x commit 1010f1d01583012077a6ffa76269dbe731d5a7c8
Author: John Mazzitelli <mazz@redhat.com>
Date:   Tue Sep 9 14:38:31 2014 -0400

    (cherry picked from commit 3fad5e975619fde2a6719616e823c90c143a3e8a
    Signed-off-by: Jay Shaughnessy <jshaughn@redhat.com>

Comment 7 Larry O'Leary 2014-09-09 22:38:40 UTC
This will not fix this issue. I think the issue is that the Bourne shell will not honor the redirect and provide the expected error code when you attempt to invoke readlink. Looking at 3.2.0.GA I see the redirects already existed yet users are still reporting this problem. When I did my own testing on Solaris 10, I ran into the same problem.

Also, the type command appears to be a BASH (Bourne Again SHell) built-in meaning that this will not work on Solaris either. We should probably investigate the use of `command` as it appears to be POSIX compliant.

I am therefore putting back to ASSIGNED as we still see './rhqctl: readlink: not found' when running rhqctl on Solaris. Additionally, I suspect the type will fail as it is a Bash build in and Solaris is using sh or bsh and not bash.

Comment 8 John Mazzitelli 2014-09-10 18:12:32 UTC
master commit:

commit 7a143a8f6b5f95bd8fe4be8c205c294b6cdc4774
Author: John Mazzitelli <mazz@redhat.com>
Date:   Wed Sep 10 14:07:42 2014 -0400

I tried this on Solaris 10, and things work.

readlink is not on Solaris 10 by default, but "command -v" does work:

# uname -sr
SunOS 5.10
# command -v ls
/usr/bin/ls
# echo $?
0
# command -v readlink
# echo $?
127

In addition, the scripts now will not attempt to even run "readlink" unless we know it exists (that is, unless "command -v readlink" exits with a status of 0).

Comment 9 John Mazzitelli 2014-09-10 20:18:33 UTC
3.3 release branch commit:

commit 87f0f39457cc6609fc8c75a00e7ad231eb3832f9
Author: John Mazzitelli <mazz@redhat.com>
Date:   Wed Sep 10 14:07:42 2014 -0400

    (cherry picked from commit 7a143a8f6b5f95bd8fe4be8c205c294b6cdc4774)

Comment 10 Simeon Pinder 2014-09-17 02:49:02 UTC
Moving to ON_QA as available for test with the following brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=385149

Comment 11 Sunil Kondkar 2014-09-23 11:43:15 UTC
Tested on JON3.3 ER03 build on Solaris 10 .

./rhqctl install using Bourne Shell now displays the warning as below:

-----------
WARNING: The readlink command is not available on this platform.
         If this script was launched from a symbolic link, errors may occur.
         Consider installing readlink on this platform.
-------------

However the ./rhqctl install displays a message "./cassandra: test: unknown operator >" and it does not proceed after installing the storage node:

--------
15:06:28,920 INFO  [org.rhq.server.control.command.Install] The storage node installer has finished with an exit value of 0
./cassandra: test: unknown operator >
15:06:28,937 INFO  [org.rhq.server.control.command.Install] Pausing to ensure RHQ Storage is initialized prior to RHQ Server installation.
#
-----------

Tried to install rhq server which results into the same message:


# ./rhqctl install --server

-------------------
WARNING: The readlink command is not available on this platform.
         If this script was launched from a symbolic link, errors may occur.
         Consider installing readlink on this platform.
16:50:28,104 INFO  [org.jboss.modules] JBoss Modules version 1.3.3.Final-redhat-1
./cassandra: test: unknown operator >
16:50:28,798 INFO  [org.rhq.server.control.command.Install] Pausing to ensure RHQ Storage is initialized prior to RHQ Server installation.
#

------------

Environment details:

# uname -sr
SunOS 5.10
# echo $SHELL
/sbin/sh

Comment 12 John Mazzitelli 2014-09-23 13:30:58 UTC
I would say close this BZ and create a new one since the current error doesn't relate to the readlink problems from the looks of it. That appears to be fixed, though it appears that another problem has shown up - cassandra scripts might not be able to run on Solaris 10, which actually could be a major problem.

Comment 13 Sunil Kondkar 2014-09-23 13:49:54 UTC
Marking this bug as verified as the new issue is addressed in another bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1145683


Note You need to log in before you can comment on or make changes to this bug.