Widziałem „Jak napisać usługę systemową, która zależy od obecności urządzenia?” ale wydaje się, że nie chodzi o podłączanie go, tylko o jego obecność.
Jest bardzo podobny, tylko potrzebna jest odwrotna zależność: zamiast (a może oprócz) usługi w zależności od urządzenia, chcesz wirtualnego urządzenie jednostka zależy od twojej usługi.
W rzeczywistości, pomimo powiązanego pytania tytuł pozornie pytając o coś przeciwnego zaakceptowana odpowiedź w wątku dokumentuje już jedną z dokładnych metod, które spowodowałyby uruchomienie urządzenia (metoda udev-rule).
Ale jeśli masz dokładny Nazwa jednostki urządzenia jest łatwiejsza do bezpośredniego użycia zależności systemowych:
Jeśli znana jest dokładna ścieżka sysfs:
Na przykład ustaliłeś, że urządzenie jest sys-subsystem-net-devices-usb0.device . Możesz użyć różnych sposobów rozszerzenia tej jednostki (mimo że jest wirtualna), na przykład foo.device.d/*.conf drop-in lub foo.device.wants/ dowiązania symboliczne (które działają tak samo jak np. multi-user.target.wants / ).
Możesz dodać [Install] konfiguracja w serwisie włącz systemctl to:
[Install]
WantedBy=sys-subsystem-net-devices-%i.device
Możesz też uzyskać ten sam wynik bezpośrednio systemctl add-wants:
# systemctl add-wants sys-subsystem-net-devices-usb0.device [email protected]
Obie metody powodują powstanie dowiązania symbolicznego, które można wykonać ręcznie ln -s.
Zwykle działa to samo dla jednostek użytkownika.
Jeśli znana jest tylko część nazwy (lub pewna kombinacja innych właściwości):
Napisz regułę udev, która pasuje do twojego urządzenia (dokładna składnia reguły udev jest poza zakresem) i ustaw ją SYSTEMD_WANTS Właściwość udev (zwana również „zmienną środowiskową urządzenia”) wskazującą twoją jednostkę:
ACTION=="add", SUBSYSTEM=="net", KERNEL=="usb*", ENV{SYSTEMD_WANTS}+="netctl-ifplugd@%k.service"
Jak wszyscy *.rules pliki są przetwarzane w porządku alfabetycznym, upewnij się, że twoja reguła zostanie umieszczona później niż własne reguły „trwałych interfejsów sieciowych” systemd.
Działa to z jednostkami użytkownika, jeśli używasz ENV{SYSTEMD_USER_WANTS}.
Możesz ulec pokusie, by użyć RUN+="/bin/systemctl start foo" przez udev. Nie rób tego. Ale jeśli tak, to przynajmniej użyj systemctl --no-block opcja, dzięki której nie stworzysz potencjalnego impasu między dwoma komponentami.
