Se un servizio è enabled, allora c'è un link simbolico da qualche parte in
/etc/systemd/system
in un file di unità, molto spesso da qualche parte in
/lib/systemd/system
Utilmente, quando si è enableun servizio, i percorsi completi del collegamento e della destinazione creati verranno stampati su stdout.
La disabilitazione del servizio elimina il collegamento simbolico, quindi il file unitario stesso non è interessato, ma il servizio non viene caricato all'avvio successivo, quando systemd legge /etc/systemd/system.
Tuttavia, è possibile caricare un servizio disabilitato e verrà avviato se viene avviato un servizio che dipende da esso ; enablee disableconfigura solo il comportamento di avvio automatico per le unità e lo stato viene facilmente ignorato.
Un servizio mascherato è un servizio il cui file di unità è un collegamento simbolico a /dev/null. Ciò rende "impossibile" il caricamento del servizio, anche se richiesto da un altro servizio abilitato.
Quando si è maskun servizio, viene creato un collegamento simbolico da /etc/systemd/systema /dev/null, lasciando intatto il file di unità originale altrove. Quando si unmaskesegue un servizio, il collegamento simbolico viene eliminato.
Tuttavia, ho notato che questi comandi non sono sempre rispettati.
Quando provo a mascherare la maggior parte dei servizi, non riesce:
$ sudo systemctl mask bluetooth.service
Failed to execute operation: Invalid argument
Naturalmente, ho interrotto prima il servizio. @Anwar suggerisce che il mascheramento è possibile solo per servizi non critici.
Smascherare un servizio mascherato, a meno che non lo mascherassi da solo, fallisce (in silenzio). Credo che ciò sia dovuto al fatto che non esiste un file unitario per il servizio ovunque, tranne che sotto forma di un collegamento simbolico a /dev/null, questa volta in /lib/systemd/system:
$ file $(locate fuse.service)
/lib/systemd/system/fuse.service: symbolic link to /dev/null
$ sudo systemctl unmask fuse.service
$ systemctl status fuse
● fuse.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
Non sono l'unico ad avere questo problema
Per smascherare effettivamente il servizio mascherato x11-common, ho dovuto eliminare il link simbolico a /dev/nulle sudo apt-get install --reinstall x11-common && sudo systemctl daemon-reload. Ora quando lo interrogo systemctl status x11-commonvedo che il servizio ha un bel cerchio verde ed è caricato e attivo (uscito) sebbene non abbia un file unitario.
Per ulteriori riferimenti questo articolo su Come utilizzare Systemctl potrebbe essere di qualche utilità.