Why udev init script default disable container support while in fact it works?

问题

Use docker run -idt -v /dev:/dev --privileged --name delete ubuntu:18.04 /bin/bash to new a container, and in container use apt-get install -y udev to install udev.

When start udev, it reports next:

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

Then, I change the init script in /etc/init.d/udev, comments next 2 parts:

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

Then, re-execute 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 ]

Then, I verify the udev in container with some udev rules added, and unplug/plug some usb device, I saw it works.

So, my question is: why in udev init script disable this in container, it's really works... Possible any special scenario I'm not aware?

UPDATE:

Also add tests next:

1. I add a simple rule next:

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

2. service udev restart

3. Unplug/Plug the usb mouse

We could see there is a file with the name "thisistestfile" in /dev:

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

回答1:

Why udev disabled in containers, it's really works

udev is a generic device manager running as a daemon on a Linux system and listening (via a netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. udev is now part of systemd.

I think it is not about udev but controversy between docker and systemd developers. Daniel Walsh has a good article series about this topic. I highly recommend this one and this one. Basically, common systems usually have a init system that running as PID 1. Upstream docker says any process can run as PID 1 in a container. This process is your application and they are recommending to run every application in a separate container. The systemd developers believe the opposite. They say you should always run an init system as PID 1 in any environment. They state that PID 1 provides services to the processes inside the container that are part of the Linux API.

Both sides are making it hard to run systemd in a docker container even though like you said it's really works.

If you want to learn more about the conflict here is another good article.

来源：https://stackoverflow.com/questions/62060604/why-udev-init-script-default-disable-container-support-while-in-fact-it-works