systemd rozwidlający czy prosty?

Piszę mój systemdplik pierwszej jednostki.

Dla Type, istnieje kilka możliwości: forking, simple, itd. Mam czytać Redhat Dokumentacja na ten temat (tabela 9.9), ale nadal nie jestem pewien, kiedy należy używać która opcja.

Jakieś wytyczne?

Co się stanie, gdy uruchomisz usługę ręcznie z wiersza polecenia (bez użycia nohuppolecenia prefiksu lub &sufiksu w celu uruchomienia go w tle lub innymi słowy, po prostu uruchom polecenie, które umieścisz w ExecStart=wierszu .servicepliku)?

a) Jeśli usługa uruchomi się i będzie działać, a monit nie wróci, dopóki nie naciśniesz klawisza Control-C lub nie zatrzymasz usługi w inny sposób: to Type = simplejest właściwy wybór.

b) Jeśli monit powróci, ale usługa nadal działa w tle (tzn. usługa sama się demonizuje), to Type = forkingjest właściwy wybór.

c) Jeśli usługa wykonuje swoje zadanie i powraca do monitu bez pozostawiania niczego uruchomionego (tj. usługa po prostu dostosowuje niektóre ustawienia jądra, wysyła polecenie do czegoś innego lub robi coś podobnego), Type = oneshotprawdopodobnie jest to właściwy wybór. W tym przypadku ExecStartusługą może być polecenie „ustawienia” czegoś i ExecStopodpowiadające mu polecenie „rozbrojenia”. Ten typ zwykle ma zalety RemainAfterExit=true, więc systemd będzie śledził „stan” tej usługi w zależności od tego, czy ostatnio „ustawiono”, czy „rozbrojono”.

Pozostałe Typewartości to przypadki szczególne. Na przykład, jeśli usługa korzysta z połączenia D-Bus, Type = dbusmoże być najlepszym wyborem. To sprawia, że systemdzdaje sobie sprawę z faktu, a następnie Systemd będzie śledzić tę usługę (i wszystko, co zależy od tego) dzięki obecności tej usługi na zawartość D-Bus.

Aby użyć Type = notify, proces musi być w stanie połączyć się z gniazdem Unix określonym w zmiennej środowiskowej $NOTIFY_SOCKETi zgłosić swój status, pisząc komunikaty do tego gniazda, gdy zajdzie taka potrzeba. Ponadto plik usługi powinien określać NotifyAccessopcję przyznania dostępu do gniazda powiadomień, stosownie do przypadku.

Istnieje narzędzie wiersza polecenia systemd-notifyi funkcja biblioteki C, sd_notify(3)której możesz użyć do wysłania tych wiadomości, ale jeśli żadna z nich nie jest odpowiednia do twoich wymagań, możesz po prostu zaimplementować własnego nadawcę wiadomości. Wymagane komunikaty są bardzo proste i wyglądają jak przypisania zmiennych powłoki: na przykład, aby powiadomić, że usługa zakończyła się pomyślnie uruchomieniem i jest gotowa obsłużyć wszelkie przychodzące żądania, usługa powinna wysłać ciąg znaków odpowiadający wyjściu printf "READY=1\n"do gniazda. Zobacz man 3 sd_notifywięcej szczegółów na temat rozpoznanych wiadomości.

Uwaga: wiele aplikacji usługowych zaprojektowanych jako przenośne dla wielu systemów uniksowych może domyślnie zachowywać się jak b), ale można sprawić, aby działały jak a) poprzez dodanie opcji (zwykle opisywanej jako „nie rozwidlaj”, „kontynuuj”) na pierwszym planie ”,„ nie demonizuj ”lub podobnie). W takim przypadku, jeśli opcja nie ma innych skutków ubocznych, preferowane byłoby dodanie opcji i użycie zachowania typu a) systemd.