1

Я использую Huawei E3531 для подключения Raspberry Zero, работающего на vanilla Raspbian 8.0 (Джесси), к Интернету. Так как это для удаленного автономного приложения, оно должно быть в состоянии автоматически вернуться в рабочее состояние после отключения питания.

Я настроил usb_modeswitch для переключения USB-режима на cdc_ether, который надежно выводит eth0 после переключения режимов. К сожалению, usb_modeswitch запускается после того, как сетевые устройства настроены, поэтому сетевой канал не запускается при холодной загрузке (он прекрасно работает при перезагрузке, где режим уже установлен правильно).

По https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ должно быть возможно добавить network-pre.target -directives к службе , чтобы заставить его работать до настройки сети:

network-pre.target - это цель, которую можно использовать для заказа услуг до того, как будет настроен любой сетевой интерфейс. Его основная цель - использование со службами брандмауэра, которые хотят установить брандмауэр до того, как какой-либо сетевой интерфейс активен

Это пассивный модуль: вы не можете запустить его напрямую, и он не втягивается службой управления сетью, а службой, которая хочет работать до него. [..] Службы, которые необходимо запустить до настройки сети, должны поместить Before = network-pre.target, а также установить Wants = network-pre.target, чтобы включить его. Таким образом, если на самом деле не существует службы, которую необходимо заказать до того, как сеть начнет работать, цель не будет задействована, что позволит избежать ненужной точки синхронизации.

Я изменил /var/lib/systemd/system/usb_modeswitch@.service и добавил директивы Before-/Wants- соответственно:

[Unit]
Description=USB_ModeSwitch
Before=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/usb_modeswitch_dispatcher --switch-systemd %I
Environment="TMPDIR=/run"

Что теперь приводит к ошибке "Цикл заказа" при загрузке:

[..]
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[ SKIP ] Ordering cycle found, skipping LSB: Raise network interfaces.
[ SKIP ] Ordering cycle found, skipping Network (Pre)
[  OK  ] Created slice system-usb_modeswitch.slice.
[..]

Вот вывод systemctl show ..:

root@raspberrypi:/lib/systemd/system# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After usb_modeswitch@.
Requires=basic.target
Requisite=
Wants=network-pre.target system-usb_modeswitch.slice
BindsTo=
PartOf=
Before=network-pre.target shutdown.target
After=systemd-journald.socket basic.target system-usb_modeswitch.slice

root@raspberrypi:/lib/systemd/system# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After usb_modeswitch@.service
Failed to get properties: Unit name usb_modeswitch@.service is not valid.
root@raspberrypi:/lib/systemd/system#

Мне также интересно, почему systemctl show работает с usb_modeswitch @. но не с помощью usb_modeswitch @ .service

Удаление двух строк в сервис-файле восстанавливает старое поведение без SKIP-ошибок.

Есть ли другой способ вызвать сетевые интерфейсы после usb_modeswitch? Нужно ли мне что-то адаптировать в systemd-конфигурации, чтобы это работало?

1 ответ1

1

Я смог решить проблему, используя следующую конфигурацию:

[Unit]
Description=USB_ModeSwitch
DefaultDependencies=no
After=local-fs.target systemd-sysctl.service
Before=network-pre.target shutdown.target
Wants=network-pre.target
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/usb_modeswitch_dispatcher --switch-systemd %I
Environment="TMPDIR=/run"

Я нашел решение с помощью этого комментария в Ubuntu-bugreport, который ссылается на похожую проблему с shorewall вместо usb_modeswitch.

DefaultDependencies определяется как:

будет неявно дополнять все настроенные зависимости типа Wants = или require = зависимостями типа After =

Я не проверял, является ли этот параметр ключевой частью конфигурации или его можно не использовать.

-

Вот полное объяснение из вышеупомянутого сообщения об ошибке (для shorewall вместо usb_modeswitch):

Shorewall не поставляется с описанием системного узла обслуживания. Такое описание генерируется при загрузке с помощью /lib /systemd /system-generators /systemd-sysv-generator на основе /etc/init.d/shorewall. Однако я заметил, что LSB-заголовок /etc/init.d/shorewall хочет, чтобы служба запускалась из /etc/rcS.d, что довольно рано, и в то же время имеет Required-Start: $ сеть $ remote_fs, что является довольно сильным требованием. Фактически, это единственный скрипт в /etc/rcS.d, который требует $ network (ну, кроме shorewall6, в котором возникает точно такая же проблема). Просмотр автоматически сгенерированного модуля в /run/systemd/generator.late/shorewall.service показывает:

DefaultDependencies=no
Before=sysinit.target shutdown.target
After=network-online.target remote-fs.target
Wants=network-online.target
Conflicts=shutdown.target

Это выглядит проблематично: sysinit.target - очень ранняя цель, большинство сервисов более высокого уровня запускаются после нее, и во многих системах (включая мою) различные зависимости делают network-online.target доступным только после sysinit.target.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .