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

Question

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

Selfabuse

Answer 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.

Linolinocut

I'm not so convinced by the answer, but still upvote it just because maybe it's the truth. You mean it print udev does not support containers just because udev is part of systemd, 'systemd guys` & docker guys have different thought on PID1? So systemdguy chose to disable it in /etc/init.d/udev?If that,it's really shameful for this 2 orgs that they can't make aglined,and furthermore for systemd guys just disble it dispite of the truth it could works with service udev start.User could chose if to enable udev, but software should not do the decision for user if it really can work. – Selfabuse

Any more direct proof related to udev & docker? You know udev really could work without systemd, systemd just a init system. – Selfabuse

Recently i try to create images with systemd for ansible testing. I started searching about init system and deamon process behaviour in docker container. Most of the init system and deamons need privileged flag. But it creates security vulnerabilities. Maybe udev is disabling itself for security reasons. But i do not know exactly. – Arabella