[Баг починен] systemd, virtualbox и dhcp

lampslave	# 9 лет, 11 месяцев назад
Темы: 32 Сообщения: 4801 Участник с: 05 июля 2011	А мы его сначала прописали, потом (частично) удалили, потом решили узнать “а чо ета ваще такое” :)

sleepycat	# 9 лет, 11 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	ну как обычно, все по законам традиций жанра xD Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 9 лет, 11 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

ну как обычно, все по законам традиций жанра xD

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

deniolp	# 9 лет, 11 месяцев назад
Темы: 5 Сообщения: 134 Участник с: 02 декабря 2011	В общем, я вот вас почитал, пошел читать маны на юнит. В конце концов, исходя из того, что писал мне lampslave Wants=network.target Before=network.target After=systemd-udev-settle.service Requires=systemd-udev-settle.service , а также из манов: Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. ,- я понял, что, чтобы решить основную проблему, из-за которой началось это обсуждение Проблема как раз в том, что никакого requires там изначально не было, и нам надо было просто правильно прописать, чтобы dhcpcd запускался после того, как udev найдёт все железки. , по идее, действительно, нужно использовать связку After/Required. Однако, ведь чуть раньше я (по совету) убирал Required и оставлял только After. И в таком состоянии юнита я решил проверить, как ведет себя systemd-udev-settle.service. Посмотрел в journalctl с помощью команды journalctl _SYSTEMD_UNIT=systemd-udev-settle.service и (к моему большому удивлению) обнаружил, что тот вообще не подавал никаких признаков жизни во время загрузки системы! Пусто! То есть, если у меня только афтер, то, как и написано в манах, мой юнит будет запускаться после только в том случае, если второй вообще будет запускаться. А если есть required, то второй юнит будет запущен насильно (и в таком случае он у меня не мертвый). Тогда у меня возникает вопрос: Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств? (Но это отдельный разговор). Так вот, я подумал, а зачем мне тогда вообще что-то про него писать? И я вернулся к дефолту юнита: [Unit] Description=dhcpcd on %I Wants=network.target Before=network.target , потом перезагрузился специально 10 раз, чтобы диагностировать прошлую проблему. А ее больше нет! Скорость загрузки была в среднем 14ms, только один раз - 25 ms. Вот что это было? Я могу только предположить, что все исправилось благодаря обновлению systemd до 192 вчера. Больше никак не могу объяснить. (Раньше то дефолт реально глючил!) В общем, спасибо вам большое, благодаря вашей помощи немного в голове что-то стало складываться насчет юнитов и системд. =) Arch awesome @各行其道@

deniolp

# 9 лет, 11 месяцев назад

Темы: 5

Сообщения: 134

Участник с: 02 декабря 2011

В общем, я вот вас почитал, пошел читать маны на юнит. В конце концов, исходя из того, что писал мне lampslave

Wants=network.target
Before=network.target
After=systemd-udev-settle.service
Requires=systemd-udev-settle.service

, а также из манов:

Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated.

,- я понял, что, чтобы решить основную проблему, из-за которой началось это обсуждение

Проблема как раз в том, что никакого requires там изначально не было, и нам надо было просто правильно прописать, чтобы dhcpcd запускался после того, как udev найдёт все железки.

, по идее, действительно, нужно использовать связку After/Required.
Однако, ведь чуть раньше я (по совету) убирал Required и оставлял только After. И в таком состоянии юнита я решил проверить, как ведет себя systemd-udev-settle.service. Посмотрел в journalctl с помощью команды

journalctl _SYSTEMD_UNIT=systemd-udev-settle.service

и (к моему большому удивлению) обнаружил, что тот вообще не подавал никаких признаков жизни во время загрузки системы! Пусто! То есть, если у меня только афтер, то, как и написано в манах, мой юнит будет запускаться после только в том случае, если второй вообще будет запускаться. А если есть required, то второй юнит будет запущен насильно (и в таком случае он у меня не мертвый). Тогда у меня возникает вопрос: Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств? (Но это отдельный разговор).
Так вот, я подумал, а зачем мне тогда вообще что-то про него писать? И я вернулся к дефолту юнита:

[Unit]
Description=dhcpcd on %I
Wants=network.target
Before=network.target

, потом перезагрузился специально 10 раз, чтобы диагностировать прошлую проблему. А ее больше нет! Скорость загрузки была в среднем 14ms, только один раз - 25 ms.
Вот что это было?
Я могу только предположить, что все исправилось благодаря обновлению systemd до 192 вчера. Больше никак не могу объяснить. (Раньше то дефолт реально глючил!)
В общем, спасибо вам большое, благодаря вашей помощи немного в голове что-то стало складываться насчет юнитов и системд.
=)

Arch awesome @各行其道@

deniolp	# 9 лет, 11 месяцев назад
Темы: 5 Сообщения: 134 Участник с: 02 декабря 2011	lampslave А мы его сначала прописали, потом (частично) удалили, потом решили узнать “а чо ета ваще такое” :) И да, это классно сказано! )) Arch awesome @各行其道@

lampslave	# 9 лет, 11 месяцев назад
Темы: 32 Сообщения: 4801 Участник с: 05 июля 2011	Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств? Есть мысль, что udev теперь отрабатывает ещё до запуска остальных сервисов, в том числе и журнала. Раньше такого не было, вот и глючило всё. Я могу только предположить, что все исправилось благодаря обновлению systemd до 192 вчера. Больше никак не могу объяснить. (Раньше то дефолт реально глючил!) А кто-то ещё говорил, что systemd не в духе Арча. Наоборот! Тут тоже никогда не знаешь, что будет завтра :)

lampslave

# 9 лет, 11 месяцев назад

Темы: 32

Сообщения: 4801

Участник с: 05 июля 2011

Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств?

Есть мысль, что udev теперь отрабатывает ещё до запуска остальных сервисов, в том числе и журнала. Раньше такого не было, вот и глючило всё.

Я могу только предположить, что все исправилось благодаря обновлению systemd до 192 вчера. Больше никак не могу объяснить. (Раньше то дефолт реально глючил!)

А кто-то ещё говорил, что systemd не в духе Арча. Наоборот! Тут тоже никогда не знаешь, что будет завтра :)

farwayer	# 9 лет, 11 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Archlinux - никогда не знаешь, что будет завтра! Нужно повесить как девиз на главной IRONY

deniolp	# 9 лет, 11 месяцев назад
Темы: 5 Сообщения: 134 Участник с: 02 декабря 2011	lampslave Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств? Есть мысль, что udev теперь отрабатывает ещё до запуска остальных сервисов, в том числе и журнала. Раньше такого не было, вот и глючило всё. Интересная мысль! (И вяжется с обновлением.. Кстати, сегодня уже до 193 обновился системд, дефолт [email protected] ведет себя хорошо..). ;-) Arch awesome @各行其道@

deniolp

# 9 лет, 11 месяцев назад

Темы: 5

Сообщения: 134

Участник с: 02 декабря 2011

lampslave
Если systemd-udev-settle.service у меня вообще не включается, то что у меня отвечает за обнаружение устройств?
Есть мысль, что udev теперь отрабатывает ещё до запуска остальных сервисов, в том числе и журнала. Раньше такого не было, вот и глючило всё.

Интересная мысль! (И вяжется с обновлением.. Кстати, сегодня уже до 193 обновился системд, дефолт [email protected] ведет себя хорошо..). ;-)

Arch awesome @各行其道@

deniolp	# 9 лет, 9 месяцев назад
Темы: 5 Сообщения: 134 Участник с: 02 декабря 2011	Кстати, тот баг исправили 10 ноября. https://bugs.archlinux.org/task/30235 Теперь дефолт [email protected] выглядит вот так: [Unit] Description=dhcpcd on %I Wants=network.target Before=network.target BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device [Service] Type=forking PIDFile=/run/dhcpcd-%I.pid ExecStart=/usr/sbin/dhcpcd -q -w %I ExecStop=/usr/sbin/dhcpcd -x %I [Install] Alias=multi-user.target.wants/[email protected] Сейчас и на реальном железе, и в вбоксе отрабатывает хорошо, без проблем.. local/dhcpcd 5.6.3-2 (base) Поэтому тему, наверно, можно пометить “решено”.. Но что такое sys-subsystem-net-devices-%i.device? Это и есть обнаружение сетевого оборудования? Arch awesome @各行其道@

deniolp

# 9 лет, 9 месяцев назад

Темы: 5

Сообщения: 134

Участник с: 02 декабря 2011

Кстати, тот баг исправили 10 ноября. https://bugs.archlinux.org/task/30235
Теперь дефолт [email protected] выглядит вот так:

[Unit]
Description=dhcpcd on %I
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=forking
PIDFile=/run/dhcpcd-%I.pid
ExecStart=/usr/sbin/dhcpcd -q -w %I
ExecStop=/usr/sbin/dhcpcd -x %I
[Install]
Alias=multi-user.target.wants/[email protected]

Сейчас и на реальном железе, и в вбоксе отрабатывает хорошо, без проблем..

local/dhcpcd 5.6.3-2 (base)

Поэтому тему, наверно, можно пометить “решено”.. Но что такое sys-subsystem-net-devices-%i.device?
Это и есть обнаружение сетевого оборудования?

Arch awesome @各行其道@

sleepycat	# 9 лет, 9 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	скорее всего да, как он формируется мне не ясно, вижу в первой если честно, но похоже, что это делается автоматически и да, быстрее всего для фикса проблем с ранним стартом юнитов. sudo systemctl -t device \| grep subsystem sys-subsystem-bluetooth-devices-hci0.device loaded active plugged /sys/subsystem/bluetooth/devices/hci0 sys-subsystem-net-devices-eth0.device loaded active plugged RTL8101E/RTL8102E PCI Express Fast Ethernet controller sys-subsystem-net-devices-wlan0.device loaded active plugged RT3090 Wireless 802.11n 1T/1R PCIe sys-subsystem-net-devices-eth0.device - RTL8101E/RTL8102E PCI Express Fast Ethernet controller Loaded: loaded Active: active (plugged) since Sun, 2012-11-25 23:06:09 MSK; 3h 9min ago Device: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/eth0 Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 9 лет, 9 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

скорее всего да, как он формируется мне не ясно, вижу в первой если честно, но похоже, что это делается автоматически и да, быстрее всего для фикса проблем с ранним стартом юнитов.

sudo systemctl -t device | grep subsystem
sys-subsystem-bluetooth-devices-hci0.device                                              loaded active plugged     /sys/subsystem/bluetooth/devices/hci0
sys-subsystem-net-devices-eth0.device                                                    loaded active plugged     RTL8101E/RTL8102E PCI Express Fast Ethernet controller
sys-subsystem-net-devices-wlan0.device                                                   loaded active plugged     RT3090 Wireless 802.11n 1T/1R PCIe

sys-subsystem-net-devices-eth0.device - RTL8101E/RTL8102E PCI Express Fast Ethernet controller
Loaded: loaded
Active: active (plugged) since Sun, 2012-11-25 23:06:09 MSK; 3h 9min ago
Device: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/eth0

deniolp	# 9 лет, 9 месяцев назад
Темы: 5 Сообщения: 134 Участник с: 02 декабря 2011	Ясно, они добавили BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device Это и есть решение первоначальной проблемы, получается.. Arch awesome @各行其道@