jmxterm:在Docker容器中“无法创建系统终端”
我有一个Docker映像，其中包含JRE、一些Java应用程序和jmxterm。后者用于运行一些特殊的管理任务。这个映像被使用在带有Docker1.13的CentOS 7服务器上(这个版本非常旧，但它是通过发行版的存储库提供的最新版本)来运行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较新的)上不可重现；
H 117jmxterm>如果我在CentOS 7服务器上使用最新的Docker(来自外部回购)而不是CentOS 7‘的本机版本1.13，则问题是不可复制的。H 218F 219
会发生什么，以及为什么错误只能在特定的环境中被复制？有什么解决办法吗？
回答 2
Stack Overflow用户
发布于 2021-06-03 23:38:24
TLDR：以java -jar jmxterm-1.0.2-uber.jar < /dev/tty的形式运行新的jmxterm版本是一个快速、肮脏和麻烦的解决方案，可以在交互式容器会话中完成自动完成和其他工作。
快速检查显示，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公用事业公司说“不提”，而我们肯定有一个。快速检查显示..。容器中确实没有PTY设备，尽管shell的标准流连接到一个！
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如果我们对最新的码头工人进行同样的检查呢？
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来说，进程连接到一些PTY，而在/dev/pts中没有它们的设备，这似乎很奇怪，但是跟踪Docker进程可以解释为什么会发生这种情况。较老的Docker在设置其他内容之前为容器分配PTY (包括输入新的挂载命名空间并将devpts挂载到容器中，或者只在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 ...>注意，newinstance挂载选项确保devpts挂载只拥有它的PTY，而不与其他挂载共享它们。这就产生了有趣的效果:容器的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 ...>这个问题是由不适当的码头工人行为引起的，但是为什么老的jmxterm在相同的环境中工作得很好呢？让我们检查一下(注意，这里使用的是Java8映像，因为旧的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，后者是负责与终端交互的库(类似于C世界中的readline )。主要jline版本之间的差异导致了jmxterm行为与当前版本just rely on tty的差异。
这个观察给我们带来了快速而又肮脏的解决方法，它既不需要更新Docker，也不需要修补jline/jmxterm串联:我们可以强制将jmxterm的stdin附加到/dev/tty，从而使jline使用此设备(现在由/proc/self/fd/0引用)，而不是/dev/pts条目(在形式上，/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现在我们有了自动完成，历史和其他我们需要的酷的东西。
Stack Overflow用户
发布于 2022-02-04 08:19:57
如果您试图在一个码头容器或kubernetes中的一个吊舱中运行一个交互式应用程序(需要tty)，那么下面的内容应该可以工作。
船坞-合成用途：
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: truehttps://stackoverflow.com/questions/67829844
复制相似问题
腾讯云开发者
