[systemd/udev] ppp: корректный автостарт system‐wide демона

  • Tutorial

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

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 7

    +5
    Я бы посоветовал у ttyUSB0 дополнительно что-нибудь проверять — серийник, симлинк или тот же VID/PID.
    Будет неприятно, если какое-то другое USB-Serial устройство — не модем — будет забрано ppp демоном.

    Но общий подход, несомненно, верен. Спасибо. 8-)
      0

      Спасибо, корректное замечание.

      0
      Ну и к 0 как к индексу тогда лучше не привязываться.
        0

        Серийные порты генерируются в зависимости от конкретного устройства, к которому как раз и привязана конфигурация. Хотя я иногда замечал, что при некоторых обстоятельствах они менялись с ttyUSB0… 2 соответственно на ttyUSB1… 3 – но это нештатная ситуация.


        Или нет?

          0

          для некоторых последовательных устройст udev генерирует т.н. persistent имена — симлинки из /dev/serial/by-id/ЧТО-то-ТАМ. В частности для usb2com у меня это работает.

        +1

        Не сталкивался с usb_modeswitch, но не проще было добавить в нужный юнит Requires=dev-serial-by\x2did-FOOBAR.device и After= на него же?

          0

          Действительно, это выглядит рациональнее.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое