Ho letto cos'è multi-user.target e la documentazione di systemd, che afferma che multi-user.target è un obiettivo speciale. Inoltre, molti degli esempi di systemd contengono quella riga.
- Perché così tanti servizi di esempio contengono quella riga?
- Cosa accadrebbe se non contenessero WantedBy=multi-user.target?
- Potresti farmi un esempio di quando sarebbe effettivamente consigliabile non includere quella riga nella definizione di un file di servizio?
- Sempre sulla stessa linea, quando è una buona idea mantenere quella linea?
Risposta accettata:
1.) multi-user.target è fondamentalmente l'equivalente più vicino del classico runlevel 3 di SysVinit che systemd ha. Quando un systemd il sistema si avvia, systemd sta cercando di far corrispondere lo stato del sistema allo stato specificato da default.target – che di solito è un alias per graphical.target o multi-user.target .
multi-user.target normalmente definisce uno stato del sistema in cui tutti i servizi di rete vengono avviati e il sistema accetterà gli accessi, ma non viene avviata una GUI locale. Questo è lo stato di sistema predefinito tipico per i sistemi server, che potrebbero essere sistemi headless montati su rack in una sala server remota.
graphical.target è un altro possibile alias per default.target . Normalmente è definito come un superset di multi-user.target :include tutto il multi-user.target fa, oltre all'attivazione di un login GUI locale. Un po' come il runlevel 5 nel classico SysVinit.
La riga WantedBy=multi-user.target in un servizio equivale essenzialmente a specificare "questo servizio dovrebbe iniziare nei runlevel 3, 4 e 5" nei sistemi SysVinit:dice a systemd che questo servizio dovrebbe essere avviato come parte del normale avvio del sistema, indipendentemente dal fatto che sia attiva o meno una GUI locale.
Tuttavia, WantedBy è separato dallo stato abilitato/disabilitato:quindi, in un altro senso, è una sorta di "preimpostazione":determina in quali condizioni può avvenire l'avvio automatico, ma solo quando il servizio è abilitato in primo luogo.
2.) se ometti WantedBy=multi-user.target line e nessun altro servizio abilitato include un Requires=your.service o Wants=your.service nella sua definizione di servizio, il tuo servizio non verrà avviato automaticamente.
systemd funziona sulle dipendenze e all'avvio, se non nulla Requires o Wants il tuo servizio, non verrà avviato anche se il servizio è abilitato.
Certo, puoi modificare il tuo default.target per aggiungere o eliminare Requires o Wants righe per tutti i servizi che desideri vengano avviati all'avvio, ma in modo da poter semplicemente rilasciare un nuovo file di servizio nel sistema e farlo funzionare per impostazione predefinita (il che rende le cose molto facili per i gestori di pacchetti software), systemd ha il WantedBy e RequiredBy parole chiave che possono essere utilizzate per inserire Wants e Requires -tipo dipendenze (rispettivamente) da "l'altra estremità".
3.) Dovresti omettere la riga se non desidera che il servizio venga avviato automaticamente all'avvio, o questo servizio fa parte di una catena di dipendenze che hai definito in modo esplicito.
Ad esempio, potresti eseguire il refactoring dell'applicazione server A e per un motivo o per l'altro decidere di suddividere alcune funzionalità facoltative in un servizio separato B, per consentire all'utente di scegliere di non installarlo se non è necessario. È quindi possibile rendere il servizio B un service-B.rpm separato e definisci B.service con WantedBy=A.service per creare systemd avvia automaticamente il servizio B ogni volta che viene avviato il servizio A, ma solo quando service-B.rpm è effettivamente installato.
Nota che un Wants o WantedBy dice solo che il sistema dovrebbe avviare un servizio ogni volta che viene avviato anche un altro servizio o destinazione, ma non specifica nulla sull'ordine di avvio/arresto. Se è necessario che il servizio B sia già in esecuzione all'avvio del servizio A, è necessario aggiungere Before=A.service nel B.service per specificare in modo esplicito la dipendenza dell'ordine di avvio.
4.) Ogni volta che lo fai desidera che il servizio abbia la capacità di essere avviato automaticamente all'avvio e che non ci siano altre dipendenze già definite.