为啥 udev init 脚本默认禁用容器支持，而实际上它可以工作？

Posted 2023-04-14

【中文标题】为啥 udev init 脚本默认禁用容器支持，而实际上它可以工作？

【英文标题】：Why udev init script default disable container support while in fact it works?为什么 udev init 脚本默认禁用容器支持，而实际上它可以工作？

【发布时间】：2020-09-15 12:38:08

【问题描述】：

使用docker run -idt -v /dev:/dev --privileged --name delete ubuntu:18.04 /bin/bash新建一个容器，在容器中使用apt-get install -y udev安装udev。

启动udev时，会报告next：

root@0947408dab9b:~# service udev start
 * udev does not support containers, not started

然后，我将/etc/init.d/udev中的init脚本改成cmets接下来的2个部分：

1) Comments next:
#if ! ps --no-headers --format args ax | egrep -q '^\['; then
#    log_warning_msg "udev does not support containers, not started"
#    exit 0
#fi

2) Comments next:
#if [ ! -w /sys ]; then
#    log_warning_msg "udev does not support containers, not started"
#    exit 0
#fi

然后，重新执行service udev start：

root@0947408dab9b:/etc/init.d# service udev start
 * Starting the hotplug events dispatcher systemd-udevd  starting version 237
  [ OK ]
 * Synthesizing the initial hotplug events... [ OK ]
 * Waiting for /dev to be fully populated...  [ OK ]

然后，我通过添加一些 udev 规则验证容器中的 udev，然后拔下/插入一些 USB 设备，我看到它可以工作。

所以，我的问题是：为什么在 udev init 脚本中在容器中禁用它，它确实有效...可能有任何我不知道的特殊情况？

更新：

接下来还要添加测试：

1.接下来我添加一个简单的规则：

root@0947408dab9b:/dev# cat /etc/udev/rules.d/100.rules
ACTION=="add", SYMLINK+="thisistestfile"

2。服务 udev 重启

3.拔下/插入 USB 鼠标

我们可以看到/dev中有一个名为“thisistestfile”的文件：

root@0947408dab9b:/dev# ls -alh /dev/thisistestfile
lrwxrwxrwx 1 root root 13 May 28 08:58 /dev/thisistestfile -> input/event12

【参考方案1】：

为什么 udev 在容器中禁用，它确实有效

udev 是一个通用设备管理器，在 Linux 系统上作为守护进程运行，并在初始化新设备或从系统中删除设备时侦听（通过 netlink 套接字）内核发送的 uevents。 udev 现在是 part of systemd。

我认为这与udev 无关，而是docker 和systemd 开发人员之间的争议。 Daniel Walsh 有一篇关于这个主题的好文章系列。我强烈推荐this one 和this one。基本上，普通系统通常有一个以PID 1 运行的初始化系统。上游docker 表示任何进程都可以在容器中以PID 1 的身份运行。此过程是您的应用程序，他们建议在单独的container 中运行每个应用程序。 systemd 开发人员的看法恰恰相反。他们说您应该在任何环境中始终以PID1 的身份运行初始化系统。他们声明PID 1 为容器内的进程提供服务，这些进程是 Linux API 的一部分。

双方都很难在docker 容器中运行systemd，尽管就像你说的it's really works。

如果您想了解更多有关冲突的信息，这里是另一个很好的article。

【讨论】：

我不太相信这个答案，但仍然赞成它，因为它可能是事实。你的意思是它打印udev does not support containers 只是因为udev is part of systemd、'systemd guy` 和docker guys 对PID1 有不同的想法？所以systemdguy 选择在/etc/init.d/udev 中禁用它？如果那样的话，这两个组织无法制作aglined 真是可耻，更何况systemd guys 不顾事实it could works with service udev start.User 只是禁用它可以选择是否启用 udev，但软件不应该为用户做决定，如果它真的可以工作。

还有更多与 udev & docker 相关的直接证据吗？你知道 udev 真的可以在没有 systemd 的情况下工作，systemd 只是一个 init 系统。

最近我尝试使用systemd 创建图像以进行ansible 测试。我开始在docker container 中搜索有关初始化系统和守护进程行为的信息。大多数初始化系统和守护进程都需要privileged 标志。但它会创建security vulnerabilities。也许udev 出于安全原因正在禁用自身。但具体我不知道。