Пакет usb_modeswitch обычно поставляется с готовыми udev‐правилами для автоматического переключения режима модема. ppp, независимо от него, помимо самого себя, включает сервис для демонизации. Эти конфигурации независимы друг от друга.
Если использовать их одновременно, может возникнуть конфликт: pppd запустится до того, как udev переключит модем usb_modeswitch -J‐ем.
Можно оставить на откуп Restart=on-failure с RestartSec=5s, но спортивно ли это?
„Just dying to be saved…” Converge
Для начала редактируем usb_modeswitch.conf – DisableSwitching=yes. Этот файл неявно используется "дефолтными" правилами – они нам не пригодятся, хоть и мешать не будут.
Теперь – systemctl disable ppp@….service. Втягивание юнита из multi-user.target нам впредь не потребуется; [Install] более не полезен.
Осталось сделать так, чтобы это всё заработало вновь – уже по‐другому.
„Beaten awake to murder again.” PsyOpus
Новое 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„Well just cease the torment, it's weighting on my mind, the pressure you apply…” TesseracT
Меня однажды очень заинтересовало умозаключение intelfx о взаимосвязи systemd и udev:
udev и systemd — офигенно мощные фреймворки, дополняющие друг друга.
systemd основан на модели зависимостей: выполнить X, если Y доступно.
udev — на модели событий: когда Y станет доступным, выполнить X.
Связь userspace с kernel действительно подчёркивается очень выразительно, и это не может не впечатлять. Продемонстрированный пример – может, немного немногообещающий или посредственный – всецело раскрывает потенциал этого инструмента.