为什么udev初始化脚本默认禁用容器支持，而实际上却起作用？

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

然后，我更改/etc/init.d/udev中的初始化脚本，在接下来的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脚本中在容器中禁用此功能，它确实有效...可能是我不知道的任何特殊情况？

UPDATE：

也添加测试：

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

Answer 1

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

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

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

双方都很难在systemd容器中运行docker，即使您说的是it's really works。

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