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

Question

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

当启动 udev 时，它报告下一个：

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

然后，我更改了 init 脚本/etc/init.d/udev，评论了接下来的两部分：

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鼠标

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

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

Answer 1

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

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

我认为这不是关于，而是与开发者udev之间的争议。Daniel Walsh有一个关于这个主题的好文章系列。我强烈推荐这个和这个。基本上，常见的系统通常都有一个以. Upstream表示任何进程都可以像在容器中一样运行。这个过程是您的应用程序，他们建议在单独的容器中运行每个应用程序。开发商的看法恰恰相反。他们说你应该在任何环境中始终将 init 系统作为1 运行。他们指出，它为容器内的进程提供服务，这些进程是 Linux API 的一部分。dockersystemdPID 1dockerPID 1systemdPIDPID 1

即使像你说的那样，双方都使得systemd在容器中运行变得困难。dockerit's really works

如果您想了解有关冲突的更多信息，请阅读另一篇好文章。