Perché alcuni servizi systemd sono nello stato "mascherato"?

43

Quando eseguo il comando sudo systemctl list-unit-files(penso che il sudo sia opzionale), ottengo un output che mostra tutti i servizi e il loro stato.

Ecco un frammento dalla mia macchina:

UNIT FILE                                  STATE
...
debian-fixup.service                       static  
debug-shell.service                        disabled
display-manager.service                    enabled 
dns-clean.service                          enabled 
dsmcad.service                             enabled 
emergency.service                          static  
failsafe-x.service                         static  
friendly-recovery.service                  masked  
fuse.service                               masked  
gdm.service                                masked  
getty-static.service                       static  
getty@.service                             enabled 
gpsd.service                               indirect
gpsdctl@.service                           static  
gpu-manager.service                        enabled 
halt-local.service                         static  
halt.service                               masked  
hostname.service                           masked
...

Mi chiedo perché alcuni servizi siano nello stato "mascherato". Penso che questo significhi "questo è meglio di 'disabilitare', perché il servizio non può essere avviato, né manualmente né da systemd".

Come posso ottenere maggiori informazioni sullo stato di un'unità di servizio?

Chi ha messo le unità nel loro rispettivo stato?

Ho provato, ad esempio, a sudo systemctl help dsmcadfar apparire solo la documentation = ...riga dal file dell'unità./etc/systemd/system/dsmcad.service

Nota: qui so esattamente cos'è il servizio dsmcad e cosa fa, l'ho installato da solo. Sono più interessato a una soluzione generale.

systemd

— KNB
fonte

48

maskè una versione più forte di disable. L'uso di disabletutti i collegamenti simbolici del file di unità specificato viene rimosso. Se si utilizzano maskle unità verranno collegate /dev/null. Questo verrà visualizzato se si controlla ad es systemctl status halt.service. Il vantaggio di maskè prevenire qualsiasi tipo di attivazione, anche manuale.

Attenzione: systemctl list-unit-fileselenca lo stato dei file dell'unità (statico, abilitato, disabilitato, mascherato, indiretto) e non ha nulla a che fare con lo stato del servizio. Per dare un'occhiata all'utilizzo dei servizisystemctl list-units .

— Kellerspeicher
fonte

8

Spiegare anche come rimuovere lo stato mascherato, se lo si desidera.

— erikbwork,

19

C'è un maske un unmaskcomando che può essere usato con systemctl. Quindi fallo systemctl unmask name_of_service.service.

— Kellerspeicher,

facendo systemctl unmask name_of_service.servicecompletamente rimosso il mio file di definizione del servizio /etc/systemd/system/, quindi ora devo aggiungerlo di nuovo. Se diventa di nuovo mascherato, rimarrò bloccato in un ciclo oO

— Eldamir,

1

Ciao Eldamir, in /etc/systemd/systemsono solo collegamenti simbolici di servizi. Dovresti aggiungere il *.servicefile /lib/systemd/systemda dove sarà collegato /etc/systemd/systemse enableil servizio. masksta creando un collegamento /dev/nulle unmasksta rimuovendo questo collegamento /etc/systemd/systeme ovviamente non fa differenza se qualcuno inserisce un file lì.

— Kellerspeicher,

3

hostname.serviceviene mascherato come ridondante perché systemdimposta il nome host (da / etc / hostname) molto presto all'avvio.

Questa impostazione è fornita dal pacchetto systemd Debian.

$ ls -l /lib/systemd/system/hostname.service
lrwxrwxrwx 1 root root 9 Apr  8 22:47 /lib/systemd/system/hostname.service -> /dev/null
$ dpkg-query --search /lib/systemd/system/hostname.service
systemd: /lib/systemd/system/hostname.service

Allo stesso modo, Debian ora può essere eseguito senza uno script shell haltsul sistema, è invece gestito da systemd-shutdown ( qui il codice sorgente ).

Se un servizio è stato mascherato manualmente, verrà invece installata la maschera /etc/systemd/system.

I servizi vengono anche mascherati quando vengono rimossi su Debian / Ubuntu . Non so perché.

— sourcejedi
fonte

La mascheratura rispetto alla rimozione dei servizi comporta la differenza tra la rimozione e l'eliminazione di un pacchetto. Nel primo caso i file di configurazione vengono conservati e pertanto potrebbe essere potenzialmente pericoloso attivare un servizio per errore (poiché il file di servizio potrebbe essere ancora nei file di configurazione). Un pacchetto rimosso avrà anche i file di servizio rimossi e non mascherati.

— Fiximan,

0

Dato che stai richiedendo informazioni sullo stato mascherato, è importante menzionare che può essere osservato in un servizio che, dopo l'avvio, ha modificato le definizioni, ricaricato (systemctl daemon-reload) e il nuovo stato NON è corretto . Un semplice esempio per capirlo è il seguente scenario:

a) the service is running well (already started)
b) edit the service definition file and delete everything in its contents
c) reload
d) state masked will be observed too

Pertanto, lo stato mascherato può essere originato da definizioni di servizio errate. Pertanto, l'utente può indurre uno stato non mascherato modificando in modo errato il servizio.

Osservazione: non sono sicuro che accada apposta o sia un semplice bug (opzione predefinita), ma potrebbe essere qualche informazione interessante da condividere

— Thiago Conrado
fonte