Abilitazione dei file di unità "collegati" in Systemd

10

Sto ancora prendendo confidenza con systemd e mi sono imbattuto in qualcosa. Non è tanto un problema, ma vorrei saperne di più su questo. Non ho trovato alcun riferimento a questo altrove.

Prima di tutto, capisco che i file di unità personalizzati per i servizi dovrebbero entrare /etc/systemd/system. Tuttavia, sarebbe utile per la gestione dei nostri server se i file di unità potessero trovarsi altrove.

Nella documentazione, ho visto che è possibile "collegare" file di unità in questo modo:

systemctl link /path/to/servicename.service

Questo creerà un collegamento a quanto sopra in /etc/systemd/system. Ora puoi avviare / interrompere questo servizio. In apparenza, questo ci è sembrato un buon modo per gestire i nostri servizi.

Tuttavia, il tentativo di abilitare tale file di unità "collegato" comporta un errore:

root@test1:/etc/systemd/system# systemctl link /root/myservice.service 
Created symlink from /etc/systemd/system/myservice.service to /root/myservice.service.

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/root/myservice.service; linked; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Failed to execute operation: No such file or directory

Utilizzando lo stesso file di unità esatto, ma copiato in /etc/systemd/systemanziché collegato, si ottiene:

root@test1:/etc/systemd/system# cp -p /root/myservice.service .

root@test1:/etc/systemd/system# systemctl daemon-reload 

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/etc/systemd/system/myservice.service; disabled; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Created symlink from /etc/systemd/system/multi-user.target.wants/myservice.service to /etc/systemd/system/myservice.service.

Da ciò, sembra che non sia possibile abilitare il collegamento in file di unità da chiamare all'avvio del sistema.

In tal caso, qual è il punto della funzionalità "link"? Dai documenti, dice:

link FILENAME

Collegare un file di unità che non si trova nei percorsi di ricerca del file di unità nel percorso di ricerca del file di unità. Ciò richiede un percorso assoluto per un file di unità. L'effetto di questo può essere annullato con disabilita. L'effetto di questo comando è che un file di unità è disponibile per l'avvio e altri comandi sebbene non sia installato direttamente nel percorso di ricerca dell'unità.

linux systemd

— Tom17
fonte

13

La pagina man è fuorviante.

~~systemctl link /root/myservice.service~~

systemctl enable /root/myservice.service

Il primo ti consente di farlo systemctl start myservice. Il secondo rende possibile l' myserviceavvio automatico (che, come sottolineato da @Julien, aggiunge automaticamente il link).

Penso ... Ho cercato di avvolgermi la testa tutto il giorno.

— Auspex
fonte

1

nota che lo systemctl enablefarà anche systemctl link, quindi non è necessario digitare i 2 comandi ;-)

— Julien

@Julien Oh, dove siamo noi quando ho scritto l'anno scorso :-) Penso di aver finalmente capito che il mese scorso!

— Auspex,

9

Quando si abilita un servizio da un percorso diverso da quello predefinito, è necessario utilizzare il percorso completo. Abilita creerà anche il collegamento per te:

systemctl enable /root/myservice.service

Una volta abilitato è possibile avviare / arrestare / stato con il nome del servizio

systemctl start myservice

Alcune avvertenze qui:

non è possibile abilitare un file di servizio che è già di per sé un collegamento
assicurarsi che il percorso sia sullo stesso disco montato. In caso contrario, systemd non sarà in grado di caricare i file dell'unità di servizio all'avvio perché il disco non sarà ancora montato e i file non saranno trovati. (consultare Impossibile caricare i file delle unità collegate Systemd sul disco montato )
a causa di un bug nel systemd non è possibile abilitare le istanze da un file di unità che si trova in un percorso non standard (consultare https://github.com/systemd/systemd/issues/661 )

— nickvane
fonte