[systemd / udev] ppp: korrekter automatischer Start des systemweiten Daemons

  • Tutorial

Das Paket wird usb_modeswitchnormalerweise mit vorgefertigten udev-Regeln zum automatischen Umschalten des Modem-Modus geliefert. ppp, unabhängig davon, beinhaltet neben sich einen Dienst zur Dämonisierung. Diese Konfigurationen sind unabhängig voneinander.



Wenn Sie sie gleichzeitig verwenden, kann ein Konflikt auftreten : Er pppdwird gestartet, bevor udev das Modem wechselt usb_modeswitch -J.


Kann mit gelassen Restart=on-failurewerden RestartSec=5s, aber ist es sportlich?


"Ich will nur gerettet werden ..." Konvergieren Sie


Bearbeiten Sie zuerst die Datei usb_modeswitch.conf - DisableSwitching=yes. Diese Datei wird implizit von den "Standard" -Regeln verwendet - sie sind für uns nicht nützlich, stören jedoch nicht.


Jetzt - systemctl disable ppp@….service. Ein Rückzug einer Einheit von multi-user.targetuns ist nicht mehr erforderlich; [Install]nicht mehr nützlich.


Es bleibt zu tun, damit es wieder funktioniert - auf andere Weise.


"Wachgeschlagen, um wieder zu morden." PsyOpus


Die neue udev-Regel soll das zuvor gestellte Problem lösen: Sie muss zuerst die Aufgabe informieren usb_modeswitchund erst dann systemd kontaktieren.


Im USB-Subsystem kann ein Gerät durch zwei Attributbezeichner definiert werden: idVendorund idProduct. Sie sind sichtbar - sie befinden sich jeweils hinter der "ID".


Das obige entspricht fast genau der ersten Zeile der neuen Konfiguration:


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

- das Zahlensystem angeben ( 0x) ist nicht erforderlich.


Jetzt wenden wir uns der Betrachtung eines anderen Subsystems zu - jetzt ist es für uns wichtig ttyUSB0. Wir wenden uns wieder unserem bevorzugten Texteditor zu:


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

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

- hier erzählt udev im richtigen Moment systemd über die Möglichkeit des Startens ppp@.


Endlich:


$ udevadm control --reload

"Nun, hör einfach auf zu quälen, es belastet mich, den Druck, den du ausübst ..." TesseracT


Ich habe mich einmal sehr für die intelfx- Schlussfolgerung über die Beziehung zwischen systemd und udev interessiert :


udev und systemd sind mächtige Frameworks, die sich gegenseitig ergänzen.

systemd basiert auf einem Abhängigkeitsmodell: Führe X aus, wenn Y verfügbar ist.
udev - auf dem Ereignismodell: Wenn Y verfügbar wird, führe X aus.

Die Verbindung zwischen Userspace und Kernel wird wirklich sehr ausdrucksstark betont, und das kann nur beeindrucken. Das gezeigte Beispiel - vielleicht ein wenig vielversprechend oder mittelmäßig - zeigt das Potenzial dieses Tools.


Jetzt auch beliebt: