Piszę mój systemd
plik 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?
Piszę mój systemd
plik 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?
Odpowiedzi:
Co się stanie, gdy uruchomisz usługę ręcznie z wiersza polecenia (bez użycia nohup
polecenia prefiksu lub &
sufiksu w celu uruchomienia go w tle lub innymi słowy, po prostu uruchom polecenie, które umieścisz w ExecStart=
wierszu .service
pliku)?
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 = simple
jest 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 = forking
jest 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 = oneshot
prawdopodobnie jest to właściwy wybór. W tym przypadku ExecStart
usługą może być polecenie „ustawienia” czegoś i ExecStop
odpowiadają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 Type
wartości to przypadki szczególne. Na przykład, jeśli usługa korzysta z połączenia D-Bus, Type = dbus
może być najlepszym wyborem. To sprawia, że systemd
zdaje 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_SOCKET
i zgłosić swój status, pisząc komunikaty do tego gniazda, gdy zajdzie taka potrzeba. Ponadto plik usługi powinien określać NotifyAccess
opcję przyznania dostępu do gniazda powiadomień, stosownie do przypadku.
Istnieje narzędzie wiersza polecenia systemd-notify
i 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_notify
wię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
.
apachectl start
Być może działając jako root? Spróbuj to zrobić i zobacz, co się stanie. Następnie wybierz a), b) lub c) z mojej odpowiedzi. Założę się, że monit powraca i Apache nadal działa, więc b) będzie odpowiedzią.
Type=notify
?
Type=notify
dodanego.
apache
, jakiego typu należy użyć?