problema di avvio del servizio systemd

Question

Questa è la prima volta che ho usato systemd e un po 'insicuro su qualcosa.

Ho un servizio che ho impostato (per GeoServer esecuzione con 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 

lo start up script fa un exec per eseguire Java/Tomcat. Avvio del servizio dalla riga di comando sembra funzionare:

sudo systemctl start geoserver 

Tuttavia, il comando non restituisce fino a quando ho Ctrl-C, questo non mi sembra giusto. Il processo java rimane comunque in esecuzione e funziona normalmente. Sono riluttante a riavviare il box per testarlo nel caso in cui questo possa causare problemi durante init e si tratta di una macchina remota e sarebbe un problema far sì che qualcuno lo indirizzi.

Answer 1

è necessario impostare correttamente "Tipo" nella sezione "Servizio":

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

Tipo

configura il tipo di start-up processo per questa unità di servizio. Uno di semplice, forking, oneshot, dbus, notifica o inattivo.

Se impostato semplice (default se né Type = né BusName =, ma ExecStart = vengono specificate), si prevede che il processo configurato con ExecStart = è il processo principale del servizio. In questa modalità, se il processo offre funzionalità ad altri processi sul sistema, i suoi canali di comunicazione devono essere installati prima che il daemon sia avviato (ad es. Zoccoli configurati da systemd, tramite attivazione socket), poiché il sistema procederà immediatamente iniziare le unità di follow-up.

Se impostato su biforcazione, è previsto che il processo configurato con ExecStart = chiamerà fork() come parte del suo avvio. Si prevede che il processo genitore esca quando l'avvio è completo e tutti i canali di comunicazione sono impostati. Il figlio continua a essere eseguito come processo del daemon principale . Questo è il comportamento dei daemon tradizionali UNIX. Se si utilizza questa impostazione, si consiglia di utilizzare anche l'opzione PIDFile = , in modo che systemd possa identificare il processo principale del daemon. systemd procederà con l'avvio delle unità di follow-up non appena si chiude il processo genitore .

Il comportamento di oneshot è simile al semplice; tuttavia, è previsto che il processo debba uscire prima che systemd avvii le unità di follow-up. RemainAfterExit = è particolarmente utile per questo tipo di servizio. Questo è l'impostazione predefinita implicita se non viene specificato né Type = o ExecStart =.

Il comportamento di dbus è simile al semplice; tuttavia, è previsto che il daemon acquisisca il nome sul bus D-Bus dal , come configurato da BusName =. systemd procederà con l'avvio delle unità di follow-up dopo che è stato acquisito il nome del bus D-Bus . Le unità di servizio con questa opzione configurate implicitamente dipendono dall'unità dbus.socket. Questo tipo è il valore predefinito se è specificato BusName =.

Il comportamento della notifica è simile alla semplice; tuttavia, è previsto che il daemon invii un messaggio di notifica tramite sd_notify (3) o una chiamata equivalente a al termine del processo di avvio . systemd procederà con con le unità di follow-up di avvio dopo che questo messaggio di notifica è stato inviato a . Se si utilizza questa opzione, NotifyAccess = (vedere sotto) deve essere impostato su per aprire l'accesso al socket di notifica fornito da systemd. Se NotifyAccess = non è impostato, sarà implicitamente impostato su main. Notare che attualmente Type = notify non funzionerà se utilizzato in combinazione con PrivateNetwork = yes.

Il comportamento di inattività è molto simile al semplice; tuttavia, l'esecuzione effettiva del file binario del servizio viene ritardata fino a quando non vengono inviati tutti i lavori. Questo può essere utilizzato per evitare l'interleaving dell'output dei servizi shell con l'output di stato sulla console.