Odpowiedzi:
Jak zauważył heemayl w komentarzu, strona podręcznika odpowiada na twoje pytanie. Z sieci:
Chce =
Słabsza wersja wymaga =. Jednostki wymienione w tej opcji zostaną uruchomione, jeśli jednostką konfigurującą jest. Jeśli jednak wymienione jednostki nie rozpoczną się lub nie można ich dodać do transakcji, nie ma to wpływu na ważność transakcji jako całości. Jest to zalecany sposób podłączenia uruchomienia jednego urządzenia do uruchomienia innego urządzenia.
I wymaga =:
Konfiguruje zależności wymagań od innych jednostek. Jeśli ta jednostka zostanie aktywowana, jednostki wymienione tutaj również zostaną aktywowane. Jeśli jedna z pozostałych jednostek zostanie dezaktywowana lub jej aktywacja się nie powiedzie, jednostka ta zostanie dezaktywowana. Tę opcję można podać więcej niż jeden raz lub w jednej opcji można określić wiele jednostek oddzielonych spacją, w którym to przypadku zostaną utworzone zależności wymagań dla wszystkich wymienionych nazw. Należy pamiętać, że zależności wymagań nie wpływają na kolejność uruchamiania lub zatrzymywania usług. Należy to skonfigurować niezależnie za pomocą opcji After = lub Before =. Jeśli jednostka foo.service wymaga usługi bar.service skonfigurowanej za pomocą Requ = i nie skonfigurowano żadnego zamówienia za pomocą After = lub Before =, wówczas obie jednostki zostaną uruchomione jednocześnie i bez opóźnień między nimi, jeśli aktywowana zostanie foo.service. Często,
Należy zauważyć, że ten typ zależności nie oznacza, że druga jednostka musi zawsze być w stanie aktywnym, gdy jednostka ta działa. W szczególności: niepomyślne sprawdzanie warunków (takie jak ConditionPathExists =, ConditionPathExists =,… - patrz poniżej) nie powoduje niepowodzenia zadania uruchamiania jednostki z zależnością Requ = =. Ponadto niektóre typy jednostek mogą się same dezaktywować (na przykład proces serwisowy może zdecydować o czystym zakończeniu lub urządzenie może zostać odłączone przez użytkownika), co nie jest propagowane do jednostek posiadających zależność Wymaga =. Użyj typu zależności BindsTo = wraz z After =, aby upewnić się, że jednostka może nigdy nie być w stanie aktywnym bez określonej innej jednostki również w stanie aktywnym (patrz poniżej).
Ze strony freedesktop.org
Twoja usługa uruchomi się tylko po osiągnięciu celu multi-user.target (nie wiem, co się stanie, jeśli spróbujesz dodać go do tego celu?), A systemd spróbuje uruchomić usługę display-manager.service przed Twoją usługą . Jeśli display-manager.service z jakiegoś powodu zawiedzie, twoja usługa będzie nadal uruchomiona (więc jeśli naprawdę potrzebujesz menedżera wyświetlania, skorzystaj Requires=
z niego). Jeśli jednak nie zostanie osiągnięty cel multi-user.target , usługa nie zostanie uruchomiona.
Jaka jest twoja usługa? Czy to system kiosku? Intuicyjnie przypuszczam, że chcesz dodać swoją usługę do multi-user.target (więc jest uruchamiany przy starcie) i mieć ściśle zależną od usługi display-manager.service poprzez Requires=display-manager.service
. Ale teraz to tylko zgadywanie.
Nasze wdrożenie serwera używa LDAP zawierającego wszystkie identyfikatory użytkowników i mapy automount. Katalogi domowe użytkowników są montowane w systemie plików NFS, a użytkownicy zazwyczaj tworzą cronjobs @reboot z kodem wykonywalnym w swoich katalogach domowych. Używamy również sssd do buforowania. Nie trzeba dodawać, że polegamy na tym, że możemy zapewnić deterministyczną kolejność rozruchu, aby ta konfiguracja działała. Opracowaliśmy bardzo zwięzłą konfigurację systemową i odkryliśmy niejasny niuans między opcjami „chce” i „wymaga”.
Jeśli podczas uruchamiania wystąpi awaria usługi i istnieje inna usługa zależna od „wymaga” w tej usłudze z „restart = zawsze” ustawionym jako opcja usługi, ta zależna usługa nie uruchomi się ponownie. Jeśli jednak masz opcję „chce”, usługa zależna uruchomi się ponownie, zgodnie z oczekiwaniami.
man systemd.unit