0

我有一个包含 JRE、一些 Java Web 应用程序和jmxterm. 后者用于运行一些临时管理任务。该映像在 CentOS 7 服务器上使用 Docker 1.13（它相当旧，但它是通过发行版的存储库提供的最新版本）来运行 Web 应用程序本身。

一切正常，但是jmxterm从 1.0.0 更新到最新版本 (1.0.2) 后，我在进入正在运行的容器并启动时收到以下警告jmxterm：

WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)

在此之后，jmxterm不会对箭头键做出反应（尝试浏览命令历史记录时），也不会提供自动完成功能。

一些快速调查表明，该问题可能会在 CentOS 7 的干净环境中重现。比如说，这就是我可以使用我需要的所有东西引导系统和容器的方法：

$ vagrant init centos/7
$ vagrant up
$ vagrant ssh
[vagrant@localhost ~]$ sudo yum install docker
[vagrant@localhost ~]$ sudo systemctl start docker
[vagrant@localhost ~]$ sudo docker run -it --entrypoint bash openjdk:11
root@0c4c614de0ee:/# wget https://github.com/jiaqi/jmxterm/releases/download/v1.0.2/jmxterm-1.0.2-uber.jar

这就是我进入容器并运行的方式jmxterm：

[vagrant@localhost ~]$ sudo docker exec -it 0c4c614de0ee sh
root@0c4c614de0ee:/# java -jar jmxterm-1.0.2-uber.jar
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
root@0c4c614de0ee:/# bea<TAB>
<Nothing happens, but autocompletion had to appear>

几点观察：

  • jmxterm无论我使用哪个图像，问题都不会出现在旧图像中；
  • jmxterm无论我使用哪个图像，新问题都会出现；
  • 该问题在我的笔记本电脑（具有更新的内核和 Docker）上无法重现；
  • 如果我在 CentOS 7 服务器上使用最新的 Docker（来自外部存储库）而不是 CentOS 7 的本机版本 1.13，则该问题无法重现。

会发生什么，为什么错误只能在特定环境中重现？有什么解决方法吗？

4

2 回答 2

0

TLDR：运行新jmxterm版本java -jar jmxterm-1.0.2-uber.jar < /dev/tty是一种快速、肮脏和 hacky 的解决方法，可以让自动完成和其他东西在交互式容器会话中工作。

快速检查显示，它试图通过运行实用程序jmxterm来确定进程使用的终端设备——可能是为了稍后获得终端功能：tty

root@0c4c614de0ee:/# strace -f -e 'trace=execve,wait4' java -jar jmxterm-1.0.2-uber.jar
execve("/opt/java/openjdk/bin/java", ["java", "-jar", "jmxterm-1.0.2-uber.jar"], 0x7ffed3a53210 /* 36 vars */) = 0
...
[pid   432] execve("/usr/bin/tty", ["tty"], 0x7fff8ea39608 /* 36 vars */) = 0
[pid   433] wait4(432, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 432
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)

该实用程序失败，状态为 1，这可能是错误消息的原因。为什么？

root@0c4c614de0ee:/# strace -y tty
...
readlink("/proc/self/fd/0", "/dev/pts/3", 4095) = 10
stat("/dev/pts/3", 0x7ffe966f2160)      = -1 ENOENT (No such file or directory)
...
write(1</dev/pts/3>, "not a tty\n", 10not a tty
) = 10

该实用程序说“不是 tty”，而我们肯定有一个。快速检查表明...尽管外壳的标准流已连接到一个，但容器中确实没有 PTY 设备！

root@0c4c614de0ee:/# ls -l /proc/self/fd
total 0
lrwx------. 1 root root 64 Jun  3 21:26 0 -> /dev/pts/3
lrwx------. 1 root root 64 Jun  3 21:26 1 -> /dev/pts/3
lrwx------. 1 root root 64 Jun  3 21:26 2 -> /dev/pts/3
lr-x------. 1 root root 64 Jun  3 21:26 3 -> /proc/61/fd

root@0c4c614de0ee:/# ls -l /dev/pts
total 0
crw-rw-rw-. 1 root root 5, 2 Jun  3 21:26 ptmx

如果我们用最新的 Docker 进行检查呢？

root@c0ebd608f79a:/# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jun  3 21:45 0 -> /dev/pts/1
lrwx------ 1 root root 64 Jun  3 21:45 1 -> /dev/pts/1
lrwx------ 1 root root 64 Jun  3 21:45 2 -> /dev/pts/1
lr-x------ 1 root root 64 Jun  3 21:45 3 -> /proc/16/fd

root@c0ebd608f79a:/# ls -l /dev/pts
total 0
crw--w---- 1 root tty  136, 0 Jun  3 21:44 0
crw--w---- 1 root tty  136, 1 Jun  3 21:45 1
crw-rw-rw- 1 root root   5, 2 Jun  3 21:45 ptmx

答对了！现在我们的 PTY 应该在它们应该在的位置，因此jmxterm可以很好地与最新的 Docker 配合使用。

看起来很奇怪的是，对于较旧的 Docker，进程连接到一些 PTY，而在 中没有它们的设备/dev/pts，但是跟踪 Docker 进程可以解释为什么会发生这种情况。较旧的 Docker在设置其他内容之前devpts为容器分配 PTY（包括进入新的挂载命名空间并挂载到其中，或者在 的情况下只进入挂载命名空间docker exec -it）：

[vagrant@localhost ~]$ sudo strace -p $(pidof docker-containerd-current) -f -e trace='execve,mount,unshare,openat,ioctl'
...
[pid  3885] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_CLOEXEC) = 9
[pid  3885] ioctl(9, TIOCGPTN, [1])     = 0
[pid  3885] ioctl(9, TIOCSPTLCK, [0])   = 0
...
[pid  3898] unshare(CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWNET|CLONE_NEWPID) = 0
...
[pid  3899] mount("devpts", "/var/lib/docker/overlay2/3af250a9f118d637bfba5701f5b0dfc09ed154c6f9d0240ae12523bf252e350c/merged/dev/pts", "devpts", MS_NOSUID|MS_NOEXEC, "newinstance,ptmxmode=0666,mode=0"...) = 0
...
[pid  3899] execve("/bin/bash", ["bash"], 0xc4201626c0 /* 7 vars */ <unfinished ...>

请注意newinstancemount 选项，它确保devptsmount 独占其 PTY 并且不与其他 mount 共享它们。这导致了一个有趣的效果：容器的 PTY 设备保留在主机上并且属于主机的devpts挂载，而容器化进程仍然可以访问它，因为它在其生命的开始时就获得了已经打开的文件描述符！

最新的 Docker 先devpts为容器挂载，然后分配 PTY，所以 PTY 属于容器的devpts挂载，在容器的文件系统中可见：

$ sudo strace -p $(pidof containerd) -f -e trace='execve,mount,unshare,openat,ioctl'
...
[pid 14043] unshare(CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET) = 0
...
[pid 14044] mount("devpts", "/var/lib/docker/overlay2/b743cf16ab954b9a4b4005bca0aeaa019c4836c7d58d6073044e5b48446c3d62/merged/dev/pts", "devpts", 
MS_NOSUID|MS_NOEXEC, "newinstance,ptmxmode=0666,mode=0"...) = 0
...
[pid 14044] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_CLOEXEC) = 7
[pid 14044] ioctl(7, TIOCGPTN, [0])     = 0
[pid 14044] ioctl(7, TIOCSPTLCK, [0])   = 0
...
[pid 14044] execve("/bin/bash", ["/bin/bash"], 0xc000203530 /* 4 vars */ <unfinished ...>

好吧，这个问题是由不适当的 Docker 行为引起的，但是为什么老jmxterm的在相同的环境中运行良好呢？让我们检查一下（注意，这里使用的是 Java 8 图像，因为旧版本jmxterm不能很好地与 Java 11 配合使用）：

root@504a7757e310:/# wget https://github.com/jiaqi/jmxterm/releases/download/v1.0.0/jmxterm-1.0.0-uber.jar
root@504a7757e310:/# strace -f -e 'trace=execve,wait4' java -jar jmxterm-1.0.0-uber.jar
execve("/usr/local/openjdk-8/bin/java", ["java", "-jar", "jmxterm-1.0.0-uber.jar"], 0x7fffdcaebdd0 /* 10 vars */) = 0
...
[pid   310] execve("/bin/sh", ["sh", "-c", "stty -a < /dev/tty"], 0x7fff1f2a1cc8 /* 10 vars */) = 0

因此，旧的jmxterm只是使用/dev/tty而不是询问tty设备名称，这是可行的，因为该设备存在于容器中：

root@504a7757e310:/# ls -l /dev/tty
crw-rw-rw-. 1 root root 5, 0 Jun  3 21:36 /dev/tty

这些版本之间的巨大区别在于jmxterm，较新的工具版本使用更高的主要版本jline，这是负责与终端交互的库（类似于readlineC 世界中的 ）。主要jline版本之间的差异导致jmxterm's 行为的差异，当前版本仅依赖tty.

这一观察使我们找到了一种既不需要更新 Docker 也不需要修补jline/jmxterm串联的快速而肮脏的解决方法：我们可能只是将jmxterm's stdin/dev/tty强制附加到，从而jline使用此设备（现在由 引用/proc/self/fd/0）而不是/dev/pts条目 (形式上，这并不总是正确的，但对于临时使用仍然足够）：

root@0c4c614de0ee:/# java -jar jmxterm-1.0.2-uber.jar < /dev/tty
Welcome to JMX terminal. Type "help" for available commands.
$>bea<TAB>
bean    beans

现在我们有了自动补全、历史记录和其他我们需要的很酷的东西。

于 2021-06-03T23:38:24.890 回答
0

如果您尝试在 docker 容器或 kubernetes 中的 pod 中运行交互式应用程序（需要 tty），那么以下应该可以工作。

对于 docker-compose 使用：

image: image-name:2.0
container_name: container-name
restart: always

stdin_open: true
tty: true

对于 Kubernetes 使用：

spec:
      containers:
      - name: web
        image: web:latest

        tty: true
        stdin: true
于 2022-02-04T08:19:57.073 回答