Problem z uruchamianiem usługi systemd

Question

Po raz pierwszy użyłem systemd i nie jestem pewien co.

Mam usługę, która wcześniej skonfigurować (na GeoServer działa pod tomcat):

[Unit] 
Description=Geoserver 
After=network.target 

[Service] 
Type=oneshot 
ExecStart=/usr/local/geoserver/bin/startup-optis.sh 
ExecStop=/usr/local/geoserver/bin/shutdown-optis.sh 
User=geoserver 

[Install] 
WantedBy=multi-user.target 

Rozruch skrypt robi exec uruchamiania Java/Tomcat. Uruchomienie usługi z poleceń wydaje się działać:

sudo systemctl start geoserver 

Jednak komenda nie zwraca aż CTRL-C, to nie wydaje mi rację. Proces java nadal działa jednak i działa normalnie. Nie chcę restartować tego pudełka, żeby to przetestować, na wypadek, gdyby to spowodowało problemy podczas init i jest to zdalna maszyna, a byłoby trudno, aby ktoś go adresował.

Answer 1

trzeba ustawić poprawny "typ" w sekcji "Service":

[Service] 
... 
Type=simple 
... 

Rodzaj

Konfiguruje typ dla tej jednostki usługowej procesu uruchamiania. Jeden z prostych, rozwidlania, tworzenia pojedynczych, dbus, powiadamiania lub bezczynności.

Jeśli ustawione na proste (domyślne jeżeli ani Type = ani BusName =, ale ExecStart = podano), oczekuje się, że proces skonfigurowany z ExecStart = jest głównym procesem obsługi. W tym trybie, jeśli proces ten oferuje funkcjonalność innym procesom w systemie, jego kanały komunikacyjne powinny być zainstalowane przed uruchomieniem demona (np. Gniazda skonfigurowane przez systemd, poprzez aktywację gniazda), ponieważ systemd natychmiast przejdzie uruchomienie kolejnych jednostek.

W przypadku ustawienia rozwidlenia oczekuje się, że proces skonfigurowany za pomocą ExecStart = wywoła fork() jako część jego uruchomienia. Proces rodzica powinien zakończyć się po zakończeniu rozruchu i skonfigurować wszystkie kanały komunikacyjne . Dziecko nadal działa jako główny proces demona . Jest to zachowanie tradycyjnych demonów UNIX. Jeśli to ustawienie jest używane, zaleca się również użycie opcji PIDFile = , aby systemd mógł zidentyfikować główny proces demona. systemd będzie kontynuował uruchamianie kolejnych jednostek, gdy zakończy się proces nadrzędny .

Zachowanie pojedynczego zdjęcia jest podobne do prostego; jednak oczekuje się, że proces musi zakończyć się, zanim systemd rozpocznie kolejne jednostki. RemainAfterExit = jest szczególnie przydatny dla tego typu usług. Ten jest domniemanym domyślnym, jeśli nie podano ani Type =, ani ExecStart =.

Zachowanie dbus jest podobne do prostego; jednak oczekuje się, że demon uzyska nazwę w magistrali D-Bus, zgodnie z konfiguracją BusName =. systemd będzie kontynuował uruchamianie kolejnych jednostek po uzyskaniu nazwy magistrali D-Bus o numerze . Jednostki usługowe z tą opcją skonfigurowały niejawnie wzmocnienie zależności od jednostki dbus.socket. Ten typ jest domyślny, jeśli podana jest nazwa BusName =.

Zachowanie powiadomienia jest podobne do zwykłego; jednak oczekuje się, że demon będzie wysyłać wiadomość z powiadomieniem przez sd_notify (3) lub równoważne wywołanie po zakończeniu uruchamiania. systemd przejdzie wraz z uruchomieniem kolejnych jednostek po wysłaniu tego powiadomienia z numerem . Jeśli ta opcja jest używana, NotifyAccess = (patrz poniżej) należy ustawić , aby otworzyć dostęp do gniazda powiadomień dostarczonego przez systemd. Jeśli NotifyAccess = nie zostanie ustawione, zostanie domyślnie ustawione na główne. Zauważ, że obecnie Typ = powiadomienie nie działa, jeśli jest używane w połączeniu z PrivateNetwork = yes.

Zachowanie się bezczynności jest bardzo podobne do prostego; jednak wykonanie rzeczywiste pliku binarnego usługi jest opóźnione, dopóki wszystkie zadania nie zostaną wysłane. Ten może być używany w celu uniknięcia przeplatania danych wyjściowych usług powłoki z wyjściem statusu stanu na konsoli.