Почему скрипт инициализации 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 отключите это в контейнере, это действительно работает ... Возможен любой особый сценарий, который я не в курсе?

ОБНОВЛЕНИЕ:

Также добавьте следующие тесты:

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 - это общий c диспетчер устройств, работающий как демон в системе Linux и прослушивающий (через netlink socket), чтобы ядро ​​отправляло сообщения, если новое устройство инициализировано или устройство удалено из системы. udev теперь часть systemd.

Я думаю, что это не о udev, а о противоречии между docker и systemd разработчиками. Дэниел Уол sh написал серию хороших статей об этом топи c. Я очень рекомендую этот и этот . Обычно в обычных системах есть система инициализации, работающая как PID 1. В апстриме docker говорится, что любой процесс может работать как PID 1 в контейнере. Этот процесс является вашим приложением, и они рекомендуют запускать каждое приложение в отдельном контейнере . Разработчики systemd считают обратное. Они говорят, что вы всегда должны запускать систему инициализации как PID 1 в любой среде. Они заявляют, что PID 1 предоставляет услуги процессам внутри контейнера, которые являются частью Linux API.

Обе стороны затрудняют запуск systemd в контейнере docker, хотя, как вы сказали, it's really works.

Если вы хотите узнать больше о конфликте, вот еще один хорошо артикул .