systemd biforcazione vs semplice?

Sto scrivendo il mio primo systemdfile di unità.

Per Type, ci sono alcune scelte: forking, simple, ecc Ho letto la documentazione RedHat su questo argomento (Tabella 9.9), ma ancora non sono sicuro se dovrei usare quale opzione.

Qualche linea guida?

Quando avvii il servizio manualmente dalla riga di comando (senza utilizzare il nohupcomando prefisso o il &suffisso per eseguirlo in background o, in altre parole, esegui semplicemente il comando che inseriresti sulla ExecStart=riga del .servicefile), cosa succede?

a) Se il servizio si avvia e continua a funzionare e il prompt non ritorna finché non si preme Control-C o si interrompe il servizio in qualche altro modo: allora Type = simpleè la scelta giusta.

b) Se il prompt ritorna ma il servizio continua a funzionare in background (ovvero il servizio si demonizza da solo), allora Type = forkingè la scelta giusta.

c) Se il servizio fa il suo lavoro e torna al prompt senza lasciare nulla in esecuzione (ovvero il servizio regola solo alcune impostazioni del kernel, invia un comando a qualcos'altro o fa qualcosa di simile), allora Type = oneshotè probabilmente la scelta giusta. In questo caso, ExecStartil servizio potrebbe essere il comando per "impostare" qualcosa, e ExecStopsarebbe il comando corrispondente per "disinserirlo". Questo tipo di solito ne beneficia RemainAfterExit=true, quindi systemd terrà traccia dello "stato" di questo servizio a seconda che l'ultima cosa sia stata "impostata" o "non impostata".

Gli altri Typevalori sono casi speciali. Ad esempio, se il servizio utilizza una connessione D-Bus, Type = dbuspotrebbe essere la scelta migliore. Si rende systemdconto del fatto e quindi systemd seguirà questo servizio (e tutto ciò che dipende da esso) dalla presenza di questo servizio sul D-Bus.

Per utilizzare Type = notify, il processo deve essere in grado di connettersi al socket Unix specificato nella variabile di ambiente $NOTIFY_SOCKETe di segnalarne lo stato scrivendo messaggi a quel socket ogni volta che è necessario. Inoltre, il file di servizio deve specificare l' NotifyAccessopzione per consentire l'accesso al socket di notifica come appropriato.

C'è un'utilità da riga di comando systemd-notifye una funzione di libreria C sd_notify(3)che puoi usare per inviare questi messaggi, ma se nessuno di questi è adatto alle tue esigenze, puoi semplicemente implementare il tuo mittente del messaggio. I messaggi richiesti sono molto semplici e sembrano assegnazioni di variabili shell: ad esempio, per notificare che il servizio ha completato con successo l'avvio ed è pronto a servire qualsiasi richiesta in arrivo, il servizio dovrebbe inviare la stringa equivalente all'output del printf "READY=1\n"socket. Vedi man 3 sd_notifyper maggiori dettagli sui messaggi riconosciuti.

Nota: molte applicazioni di servizio progettate per essere portatili con molti sistemi in stile Unix possono comportarsi come b) per impostazione predefinita, ma possono essere fatte funzionare come a) aggiungendo un'opzione (di solito descritta come "non fork", "continua a funzionare in primo piano "," non demonizzare "o simili). In tal caso, se l'opzione non ha altri effetti collaterali, sarebbe preferibile aggiungere l'opzione e usare il comportamento a) systemd.