10

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
atline
  • 28,355
  • 16
  • 77
  • 113

1 Answers1

4

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.

Doruk Eren Aktaş
  • 2,121
  • 8
  • 23
  • 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 `systemd`guy 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. – atline Jun 06 '20 at 07:43
  • Any more direct proof related to udev & docker? You know udev really could work without systemd, systemd just a init system. – atline Jun 06 '20 at 07:45
  • 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](https://blog.trendmicro.com/trendlabs-security-intelligence/why-running-a-privileged-container-in-docker-is-a-bad-idea/#:~:text=As%20the%20privileged%20container%20is,the%20available%20capabilities%2C%20including%20CAP_SYS_ADMIN.). Maybe `udev` is disabling itself for security reasons. But i do not know exactly. – Doruk Eren Aktaş Jun 06 '20 at 07:56