给定podman安装在linux系统和名为baz.service的systemd单元上:
# /etc/systemd/system/baz.service
[Service]
ExecStart=/usr/bin/podman run --rm --tty --name baz alpine sh -c 'while true; do date; sleep 1; done'
ExecStop=/usr/bin/podman stop baz
然后baz.service启动:
# systemctl daemon-reload
# systemctl start baz.service
然后,当我检查设备的状态时,在/system.slice/baz.service cgroup 中看不到sh
or sleep
进程
# systemctl status baz
● baz.service
Loaded: loaded (/etc/systemd/system/baz.service; static; vendor preset: enabl
Active: active (running) since Sat 2019-08-10 05:50:18 UTC; 14s ago
Main PID: 16910 (podman)
Tasks: 9
Memory: 7.3M
CPU: 68ms
CGroup: /system.slice/baz.service
└─16910 /usr/bin/podman run --rm --tty --name baz alpine sh -c while
# ...
我期望看到sh
and sleep
子项处于我的baz.service状态,因为我听说过redhat的人说podman使用传统的fork-exec模型。
如果podman做了fork和exec,那么我sh
和sleep
process不会是podman的子代,并且与原始podman进程在同一个cgroup中吗?
我期望能够使用systemd和podman来管理我的容器,而不必让孩子们去另一个父母那里,而不必离开我的baz.service ssystemd单元。
综观输出ps
我可以看到,sh
和sleep
实际上是一个叫做不同的子进程conmon
。我不确定conmon的来源或启动方式,但是systemd没有捕获到它。
# ps -Heo user,pid,ppid,comm
# ...
root 17254 1 podman
root 17331 1 conmon
root 17345 17331 sh
root 17380 17345 sleep
从输出中可以明显看出,我的baz.service单元没有管理conmon-> sh-> sleep chain。
- podman与Docker客户端服务器模型有何不同?
- Podman的常识与Docker的容器有何不同?
也许它们都是容器运行时,dockerd
守护进程正是人们想要摆脱的。
因此,也许docker就像:
- dockerd守护程序
- 码头工人cli
- 容器化容器运行时
而podman就像:
- 播客
- 普通容器运行时
因此,也许podman使用传统的fork exec模型,但不是叉臂cli派生和执行,而是常见的过程。
我感到困惑。