Tomcat 9 在 docker 上运行 - 找不到 /usr/local/tomcat/bin/setclasspath.sh

Question

我在 docker 上运行 tomcat (tomcat:9-jre11)，启动它时，它会记录以下内容，然后崩溃：

Cannot find /usr/local/tomcat/bin/setclasspath.sh
This file is needed to run this program

我的第一个问题实际上是进入容器，因为我不能在崩溃的容器上使用 docker exec，但我通过在 Rancher 中将入口点设置为 /bin/bash 来管理它。

现在 setclasspath.sh 非常多地位于容器内的 /usr/local/tomcat/bin/ 中。 它以前具有所有读取和执行权限，我已将其设置为 777 以确保仍然存在相同的问题。 更改所有者也是如此（tomcat 似乎正在使用 root，即使我在另一个用户上手动启动 catalina.sh 并更改了文件所有者）。 我使用了笨拙的方法并将整个该死的文件夹设置为 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

我查看了 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

条件内的-r很糟糕。 我读过它，如果文件存在并且可读，它会满足所有条件。 我添加了带有-a和-f条件的 elif，并且确实返回 true，但权利似乎是问题，尽管它们是否设置为 777。 我也在脚本中添加了一个 whoami，它是 root 用户，所以不是所有权问题。

startup.sh 脚本有一个类似的问题，带有 -x 条件，它无法找到 catalina.sh ...

Answer 1

我们今天刚刚偶然发现了这个问题。

我们有一个从 16.04 升级的 Ubuntu 18.04 服务器。 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

内核是： 4.15.0-154-generic x86_64

在这台机器上，运行当前版本的 tomcat:9-jre11 [0] 会导致与您的问题中描述的相同的问题。

为了缩小范围，我们刚刚开始了这样的 bash：

docker run -it --rm --entrypoint=/bin/bash tomcat:9-jre11

现在出现了您观察到的奇怪行为，这与 tomcat 完全无关：

root@f338debf92f6:/usr/local/tomcat# [[ -r /bin/bash ]]
root@f338debf92f6:/usr/local/tomcat# echo $?
1

在我们测试的任何其他机器上，结果都符合预期，例如：

root@0083a80a9ec2:/usr/local/tomcat# [[ -r /bin/bash ]]
root@0083a80a9ec2:/usr/local/tomcat# echo $?
0

不幸的是，我无法使用新安装的 Ubuntu 18.04 重现该行为。 我什至降级了内核版本并从 xenial repo 安装了 docker。

试图用谷歌搜索我找到的解决方案： https ://github.com/alpinelinux/docker-alpine/issues/156#issuecomment-912645029

所以我尝试了 strace，这里的问题是可见的：

在我们的 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
...

在我测试过的任何其他机器上：

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

研究 faccessat2 系统调用表明它不应该返回 EPERM [1]。 我无法确定这种行为是在哪里引入的——介于 glibc 和 seccomp 之间，但这一切都归结为运行时对于这个新的系统调用来说太旧了。

以下是我们提出的解决方案：

1. 升级你的机器——虽然这可能不可行:)
2. 使用基于旧版本 Debian/Ubuntu 的 tomcat 映像。 对我们来说tomcat:9.0.64-jre11-openjdk-slim-bullseye工作得很好。
3. 使用--privileged开关运行容器。 这规避了系统调用权限问题，但通常是个坏主意

参考

0. 摘要 sha256:f0c2eb420166a7d609c0031699e0778e11256f280cc2bfb5bfd61cde7ae45c61
1. https://man7.org/linux/man-pages/man2/faccessat.2.html

Answer 2

问题描述如下：

https://github.com/docker-library/tomcat/issues/269

Tomcat Container 中的基本映像 (Eclipse Temurin) 已更新为基于 Ubuntu LTS 22.04 Jammy 的 Temurin 映像。

如果您在主机上使用旧的 Docker 版本和 libseccomp，您将遇到 bash 中带有“-r”标志的问题。

我们的解决方案是使用 Tomcat tomcat:9-jdk11-temurin-focal

Answer 3

我在运行 tomcat:9-jdk8 映像时遇到了同样的问题，该映像在 debian 10.3 VM 上运行，该 VM 不再是最新的。

通过以下方式升级整个系统

sudo apt-get update
sudo apt upgrade
-> reboot VM

解决了这个问题。 现在的实际版本：docker-client：20.10.17，docker 引擎：19.03.9，kernel：4.19.0-21-amd64

有趣的是：该问题仅在运行在此过时系统上构建的映像时出现。 在我们的 jenkins 服务器上构建的“相同”tomcat 映像在我的本地过时 VM 上启动时没有问题。