- PVSM.RU - https://www.pvsm.ru -
Пакет usb_modeswitch
обычно поставляется с готовыми udev‐правилами для автоматического переключения режима модема. ppp
, независимо от него, помимо самого себя, включает сервис для демонизации. Эти конфигурации независимы друг от друга.
Если использовать их одновременно, может возникнуть конфликт: pppd
запустится до того, как udev переключит модем usb_modeswitch -J
‐ем.
Можно оставить на откуп Restart=on-failure
с RestartSec=5s
, но спортивно ли это?
Для начала редактируем usb_modeswitch.conf – DisableSwitching=yes
. Этот файл неявно используется "дефолтными" правилами – они нам не пригодятся, хоть и мешать не будут.
Теперь – systemctl disable ppp@….service
. Втягивание юнита из multi-user.target
нам впредь не потребуется; [Install]
более не полезен.
Осталось сделать так, чтобы это всё заработало вновь – уже по‐другому.
Новое udev‐правило призвано решить проблему, поставленную ранее: оно должно сначала сообщить задачу usb_modeswitch
‐у, и только потом обратиться к systemd.
В подсистеме USB устройство можно определить двумя атрибутами‐идентификаторами: idVendor
и idProduct
. Их можно увидеть lsusb‐ом – они располагаются соответственно после "ID".
Сказанное почти в точности соответствует первой строке новой конфигурации:
$ su -
$ cd /etc/udev/rules.d
$ cat > 20-provider-modem.rules <<< …
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="…", ATTR{idProduct}=="…", RUN+="/usr/sbin/usb_modeswitch -v $attr{idVendor} -p $attr{idProduct} -J"
– уточнять систему счисления (0x
) не нужно.
Теперь мы переходим к рассмотрению другой подсистемы – теперь для нас важен ttyUSB0
. Снова обращаемся к любимому текстовому редактору:
$ cat >> 20-provider-modem.rules <<< …
SUBSYSTEM=="tty", KERNEL=="ttyUSB0", TAG+="systemd", ENV{SYSTEMD_WANTS}="ppp@provider.service"
– здесь udev в надлежащий момент сообщает systemd о возможности запуска ppp@
.
Наконец:
$ udevadm control --reload
Меня однажды очень заинтересовало умозаключение intelfx [1] о взаимосвязи systemd и udev [2]:
udev и systemd — офигенно мощные фреймворки, дополняющие друг друга.
systemd основан на модели зависимостей: выполнить X, если Y доступно.
udev — на модели событий: когда Y станет доступным, выполнить X.
Связь userspace с kernel действительно подчёркивается очень выразительно, и это не может не впечатлять. Продемонстрированный пример – может, немного немногообещающий или посредственный – всецело раскрывает потенциал этого инструмента.
Автор: kalterfive
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/193772
Ссылки в тексте:
[1] intelfx: https://habrahabr.ru/users/intelfx/
[2] о взаимосвязи systemd и udev: https://vk.com/intelfx?w=wall16705526_963
[3] Источник: https://habrahabr.ru/post/311268/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.