[英]Tomcat 9 running on docker - Cannot find /usr/local/tomcat/bin/setclasspath.sh
I'm running a tomcat (tomcat:9-jre11) on docker, when launching it, it logs the following, then crashes:我在 docker 上运行 tomcat (tomcat:9-jre11),启动它时,它会记录以下内容,然后崩溃:
Cannot find /usr/local/tomcat/bin/setclasspath.sh
This file is needed to run this program
My first issue was actually getting inside the container because I can't use docker exec on a crashed container, but I managed it by setting an entry point as /bin/bash in Rancher.我的第一个问题实际上是进入容器,因为我不能在崩溃的容器上使用 docker exec,但我通过在 Rancher 中将入口点设置为 /bin/bash 来管理它。
Now setclasspath.sh is very much in the /usr/local/tomcat/bin/ inside the container.现在 setclasspath.sh 非常多地位于容器内的 /usr/local/tomcat/bin/ 中。 It previously had all read and execution rights, I've set it to 777 just to be sure, still have the same issue.
它以前具有所有读取和执行权限,我已将其设置为 777 以确保仍然存在相同的问题。 Same goes with changing the owner (tomcat seems to be using root, even if I launch the catalina.sh manually on another user, having changed the file owner).
更改所有者也是如此(tomcat 似乎正在使用 root,即使我在另一个用户上手动启动 catalina.sh 并更改了文件所有者)。 I used the heavy handed approch and set the whole damn folder as 777, and still the same:
我使用了笨拙的方法并将整个该死的文件夹设置为 777,但还是一样:
drwxrwxrwx 1 root root 4096 Jun 29 14:53 .
drwxr-xr-x 1 root root 4096 Jun 29 14:31 ..
-rwxrwxrwx 1 root root 34699 Jun 2 21:08 bootstrap.jar
-rwxrwxrwx 1 root root 25523 Jun 29 14:00 catalina.sh
-rwxrwxrwx 1 root root 1664 Jun 2 21:08 catalina-tasks.xml
-rwxrwxrwx 1 root root 2007 Jun 28 03:01 ciphers.sh
-rwxrwxrwx 1 root root 25410 Jun 2 21:08 commons-daemon.jar
-rwxrwxrwx 1 root root 211777 Jun 2 21:08 commons-daemon-native.tar.gz
-rwxrwxrwx 1 root root 1932 Jun 28 03:01 configtest.sh
-rwxrwxrwx 1 root root 9110 Jun 28 03:01 daemon.sh
-rwxrwxrwx 1 root root 1975 Jun 28 03:01 digest.sh
-rwxrwxrwx 1 root root 3392 Jun 28 03:01 makebase.sh
-rwxrwxrwx 1 root root 3718 Jun 28 03:01 setclasspath.sh
-rwxrwxrwx 1 root root 1912 Jun 28 03:01 shutdown.sh
-rwxrwxrwx 1 root root 1914 Jun 28 03:01 startup.sh
-rwxrwxrwx 1 root root 46898 Jun 2 21:08 tomcat-juli.jar
-rwxrwxrwx 1 root root 5550 Jun 28 03:01 tool-wrapper.sh
-rwxrwxrwx 1 root root 1918 Jun 28 03:01 version.sh
I've looked at the catalina.sh script, the part which cause the issue is the following:我查看了 catalina.sh 脚本,导致问题的部分如下:
if [ -r "$CATALINA_HOME"/bin/setclasspath.sh ]; then
. "$CATALINA_HOME"/bin/setclasspath.sh
else
echo "Cannot find $CATALINA_HOME/bin/setclasspath.sh"
echo "This file is needed to run this program"
fi
The -r inside the condition is borked.条件内的-r很糟糕。 I've read it looked if the file exists and is readable, it fill all conditions.
我读过它,如果文件存在并且可读,它会满足所有条件。 I've added elif with -a and -f condition and the do return true, but the rights seems to be the issue despite them being set to 777 or not.
我添加了带有-a和-f条件的 elif,并且确实返回 true,但权利似乎是问题,尽管它们是否设置为 777。 I've add a whoami inside the script as well, and it's the root user, so not an issue of ownership.
我也在脚本中添加了一个 whoami,它是 root 用户,所以不是所有权问题。
The startup.sh script has a similar issue, with a -x condition, where it cannot find the catalina.sh... startup.sh 脚本有一个类似的问题,带有 -x 条件,它无法找到 catalina.sh ...
We just stumbled over this very problem today.我们今天刚刚偶然发现了这个问题。
We have an Ubuntu 18.04 server that was upgraded from 16.04.我们有一个从 16.04 升级的 Ubuntu 18.04 服务器。 The versions of the docker packages read:
docker 软件包的版本如下:
docker-ce/now 5:19.03.1~3-0~ubuntu-xenial amd64
docker-ce-cli/now 5:19.03.1~3-0~ubuntu-xenial amd64
docker-compose/bionic,bionic,now 1.17.1-2 all
Kernel is: 4.15.0-154-generic x86_64
内核是:
4.15.0-154-generic x86_64
On this machine, running a current version of tomcat:9-jre11 [0] results in the same problem as depicted in your question.在这台机器上,运行当前版本的 tomcat:9-jre11 [0] 会导致与您的问题中描述的相同的问题。
To narrow it down, we just started a bash like this:为了缩小范围,我们刚刚开始了这样的 bash:
docker run -it --rm --entrypoint=/bin/bash tomcat:9-jre11
Now here comes the strange behavior you observed, which is completely unrelated to tomcat:现在出现了您观察到的奇怪行为,这与 tomcat 完全无关:
root@f338debf92f6:/usr/local/tomcat# [[ -r /bin/bash ]]
root@f338debf92f6:/usr/local/tomcat# echo $?
1
On any other machine we tested, the result is as expected, eg:在我们测试的任何其他机器上,结果都符合预期,例如:
root@0083a80a9ec2:/usr/local/tomcat# [[ -r /bin/bash ]]
root@0083a80a9ec2:/usr/local/tomcat# echo $?
0
Unfortunately I was not able to reproduce the behavior using a freshly installed Ubuntu 18.04.不幸的是,我无法使用新安装的 Ubuntu 18.04 重现该行为。 I even downgraded the kernel version and installed docker from the xenial repo.
我什至降级了内核版本并从 xenial repo 安装了 docker。
Trying to google a solution I found: https://github.com/alpinelinux/docker-alpine/issues/156#issuecomment-912645029试图用谷歌搜索我找到的解决方案: https ://github.com/alpinelinux/docker-alpine/issues/156#issuecomment-912645029
So I tried strace, and here the problem is visible:所以我尝试了 strace,这里的问题是可见的:
On our Ubuntu 18.04:在我们的 Ubuntu 18.04 上:
...
read(255, "#!/bin/bash\n[[ -r /bin/bash ]]\n", 31) = 31
faccessat2(AT_FDCWD, "/bin/bash", R_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
read(255, "", 31) = 0
...
And on any other machine I tested:在我测试过的任何其他机器上:
...
read(255, "#!/bin/bash\n[[ -r /bin/bash ]]\n", 31) = 31
faccessat2(AT_FDCWD, "/bin/bash", R_OK, AT_EACCESS) = -1 ENOSYS (Function not implemented)
faccessat(AT_FDCWD, "/bin/bash", R_OK) = 0
read(255, "", 31)
...
Researching the faccessat2 system call shows that it should not return EPERM [1].研究 faccessat2 系统调用表明它不应该返回 EPERM [1]。 I could not quite pinpoint where this behavior is introduced - somewhere between glibc and seccomp, but it all boils down to the runtime being too old for this new syscall.
我无法确定这种行为是在哪里引入的——介于 glibc 和 seccomp 之间,但这一切都归结为运行时对于这个新的系统调用来说太旧了。
Here are the solutions we came up with:以下是我们提出的解决方案:
tomcat:9.0.64-jre11-openjdk-slim-bullseye
worked fine.tomcat:9.0.64-jre11-openjdk-slim-bullseye
工作得很好。--privileged
switch.--privileged
开关运行容器。 This circumvents the syscall privilege problem, but would be generally a bad ideaReferences参考
The Problem is descriped here:问题描述如下:
https://github.com/docker-library/tomcat/issues/269 https://github.com/docker-library/tomcat/issues/269
The Base Image (Eclipse Temurin) from the Tomcat Container was updated to Ubuntu LTS 22.04 Jammy based Temurin image. Tomcat Container 中的基本映像 (Eclipse Temurin) 已更新为基于 Ubuntu LTS 22.04 Jammy 的 Temurin 映像。
If you use an old Docker Version and libseccomp on your Host you will run into the Problem with the "-r" Flag in bash.如果您在主机上使用旧的 Docker 版本和 libseccomp,您将遇到 bash 中带有“-r”标志的问题。
Our Solution was to use the Tomcat tomcat:9-jdk11-temurin-focal
我们的解决方案是使用 Tomcat
tomcat:9-jdk11-temurin-focal
I had the same problem running a tomcat:9-jdk8 image, running on a debian 10.3 VM that was no more up-to-date.我在运行 tomcat:9-jdk8 映像时遇到了同样的问题,该映像在 debian 10.3 VM 上运行,该 VM 不再是最新的。
Upgrading the whole system by通过以下方式升级整个系统
sudo apt-get update
sudo apt upgrade
-> reboot VM
solved the problem.解决了这个问题。 Actual versions now: docker-client: 20.10.17, docker engine: 19.03.9, kernel: 4.19.0-21-amd64
现在的实际版本:docker-client:20.10.17,docker 引擎:19.03.9,kernel:4.19.0-21-amd64
Interestigly: The problem only occured when running the image that was built on this outdated system.有趣的是:该问题仅在运行在此过时系统上构建的映像时出现。 The 'same' tomcat image built on our jenkins server started without problems on my local outdated VM.
在我们的 jenkins 服务器上构建的“相同”tomcat 映像在我的本地过时 VM 上启动时没有问题。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.