Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WLP_INSTALL_DIR set incorrectly when wlp/bin is a symbolic link #27971

Closed
jimblye opened this issue Mar 21, 2024 · 0 comments · Fixed by #27972
Closed

WLP_INSTALL_DIR set incorrectly when wlp/bin is a symbolic link #27971

jimblye opened this issue Mar 21, 2024 · 0 comments · Fixed by #27972
Assignees
Labels
release bug This bug is present in a released version of Open Liberty release:24004

Comments

@jimblye
Copy link
Member

jimblye commented Mar 21, 2024

Describe the bug
This is an edge case where the the wlp/bin directory is a symbolic link. In this case, WLP_INSTALL_DIR might resolve to the parent of the symbolic link (logical path) rather than the real path (physical path) of the wlp directory. It works fine if there is a symbolic link somewhere in the ancestry of the bin directory, but fails in some cases when bin is a symbolic link.

The problem is that we first append "/.." to the bin directory, before trying to resolve the path. At that point, we are now trying to resolve the parent of the symbolic link, which normally won't resolve to anything different unless the parent or another ancestor directory is also a symbolic link.

Steps to Reproduce

cd wlp
mv bin realbin
ln -s realbin bin
./server start

Expected behavior
The server should start without error, but since the WLP_INSTALL_DIR is not calculated correctly, the server script might not be able to find etc/server.env, etc/jvm.options, /bin/tools/ws-server.jar, etc...

Diagnostic information:

  • OpenLiberty Version: [e.g. 24.0.0.1 - 24.0.0.2]

Additional context
Support for wlp/bin as a symbolic link was only recently added in 23.0.0.12, and then it was broken by a change in 24.0.0.1.

Trace from 23.0.0.12 (The BEFORE case - working case):

+++ dirname /home/mfps/IBM/WebSphere/Liberty/bin/server
++ dirname=/home/mfps/IBM/WebSphere/Liberty/bin
+++ findRealPath /home/mfps/IBM/WebSphere/Liberty/bin/..
+++ path=/home/mfps/IBM/WebSphere/Liberty/bin/..
+++ command -v realpath
++++ realpath /home/mfps/IBM/WebSphere/Liberty/bin/..
+++ resolvedPath=/home/mfps/IBM/LibertyRuntime/230012/wlp

Trace from 24.0.0.1 (failing case):

++ case $uname in
+++ dirname /home/mfps/IBM/WebSphere/Liberty/bin/server
++ dirname=/home/mfps/IBM/WebSphere/Liberty/bin
+++ unset CDPATH
+++ cd /home/mfps/IBM/WebSphere/Liberty/bin/..
+++ pwd
++ WLP_INSTALL_DIR=/home/mfps/IBM/WebSphere/Liberty
+++ findRealPath /home/mfps/IBM/WebSphere/Liberty
+++ path=/home/mfps/IBM/WebSphere/Liberty
+++ command -v realpath
++++ realpath /home/mfps/IBM/WebSphere/Liberty
+++ resolvedPath=/home/mfps/IBM/WebSphere/Liberty
+++ '[' -z /home/mfps/IBM/WebSphere/Liberty ']'

The server script references WLP_INSTALL_DIR to find other files:

${WLP_INSTALL_DIR}/etc/server.env
${WLP_INSTALL_DIR}/java/java.env
${WLP_INSTALL_DIR}/etc/default.env
${WLP_INSTALL_DIR}/etc/jvm.options
${WLP_INSTALL_DIR}/usr/shared/jvm.options
${WLP_INSTALL_DIR}/lib/platform/java/java9.options
${WLP_INSTALL_DIR_QUOTED}/bin/tools/ws-javaagent.jar
${WLP_INSTALL_DIR_QUOTED}/bin/tools/ws-server.jar
${WLP_INSTALL_DIR}/lib/native/zos/s390x/bbgzcsl (zOS only)
${WLP_INSTALL_DIR}/lib/native/zos/s390x/nls/%N.cat (zOS only)

And uses it to set other variables:
WLP_DEFAULT_USER_DIR=${WLP_INSTALL_DIR}/usr which matters if WLP_USER_DIR is not defined.

@jimblye jimblye added the release bug This bug is present in a released version of Open Liberty label Mar 21, 2024
@jimblye jimblye self-assigned this Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release bug This bug is present in a released version of Open Liberty release:24004
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants