[systemd / udev] ppp: correct auto start of the system ‐ wide daemon

A package usb_modeswitchusually comes with ready-made udev rules for automatically switching modem mode. ppp, independently of it, besides itself, includes a service for demonization. These configurations are independent of each other.

If you use them at the same time, a conflict may arise : it pppdwill start before udev switches the modem usb_modeswitch -J.

Can be left Restart=on-failurewith RestartSec=5s, but is it sporty?

“Just dying to be saved ...” Converge

First, edit usb_modeswitch.conf - DisableSwitching=yes. This file is implicitly used by the "default" rules - they will not be useful to us, although they will not interfere.

Now - systemctl disable ppp@….service. Retraction of a unit from multi-user.targetus will no longer be required; [Install]no longer useful.

It remains to make sure that it all works again - already in a different way.

“Beaten awake to murder again.” Psyopus

The new udev rule is designed to solve the problem posed earlier: it must first inform the task usb_modeswitch, and only then contact systemd.

In the USB subsystem, a device can be defined by two attribute identifiers: idVendorand idProduct. They can be seen lsusb th - they are located respectively after the "ID".

The above almost exactly corresponds to the first line of the new configuration:

$ 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"

- specify the number system ( 0x) is not necessary.

Now we turn to the consideration of another subsystem - now it is important for us ttyUSB0. Again, we turn to our favorite text editor:

$ cat >> 20-provider-modem.rules <<< …

SUBSYSTEM=="tty", KERNEL=="ttyUSB0", TAG+="systemd", ENV{SYSTEMD_WANTS}="ppp@provider.service"

- here udev at the right moment tells systemd about the possibility of starting ppp@.

Finally:

$ udevadm control --reload

“Well just cease the torment, it's weighting on my mind, the pressure you apply ...” TesseracT

I was once very interested in the intelfx inference about the relationship between systemd and udev :

udev and systemd are awesomely powerful frameworks that complement each other.

systemd is based on a dependency model: execute X if Y is available.
udev - on the event model: when Y becomes available, execute X.

The connection between userspace and kernel is really emphasized very expressively, and this cannot but impress. The demonstrated example - maybe a little promising or mediocre - fully reveals the potential of this tool.