Pourquoi certains services systemd sont-ils dans l'état «masqué»?

43

Lorsque je lance la commande sudo systemctl list-unit-files(je pense que le sudo est optionnel), je reçois une sortie qui montre tous les services et leur état.

Voici un extrait de ma machine:

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
...

Je me demande pourquoi certains services sont dans l'état "masqué". Je pense que cela signifie "c'est mieux que de" désactiver ", car le service ne peut pas être démarré, ni manuellement ni par systemd".

Comment puis-je obtenir plus d'informations sur l'état d'une unité de service?

Qui a mis les unités dans leur état respectif?

J'ai essayé, par exemple, sudo systemctl help dsmcadqui ne fait apparaître que la documentation = ...ligne du fichier unité./etc/systemd/system/dsmcad.service

Remarque: je sais exactement ce que le service dsmcad est et ce qu'il fait, je l'ai installé moi-même. Je suis plus intéressé par une solution générale.

systemd

— knb
source

48

maskest une version plus forte de disable. En utilisant disabletous les liens symboliques du fichier de l' unité spécifiée sont supprimés. Si vous utilisez maskles unités seront liées à /dev/null. Ceci sera affiché si vous vérifiez par exemple par systemctl status halt.service. L'avantage maskest d'empêcher tout type d'activation, même manuelle.

Attention: systemctl list-unit-filesrépertorie l'état des fichiers de l'unité (statique, activé, désactivé, masqué, indirect) et n'a rien à voir avec l'état du service. Pour regarder l' utilisation des servicessystemctl list-units .

— Kellerspeicher
source

8

Veuillez également expliquer comment supprimer l’état masqué, si vous le souhaitez.

— erikbwork

19

Il y a maskune unmaskcommande et une qui peut être utilisé avec systemctl. Alors faites-le systemctl unmask name_of_service.service.

— Kellerspeicher

faire systemctl unmask name_of_service.servicecomplètement supprimé mon fichier de définition de service de /etc/systemd/system/, donc maintenant je dois le rajouter à nouveau. Si ça se masque à nouveau, je serai coincé dans une boucle oO

— Eldamir

1

Bonjour Eldamir, dans ne /etc/systemd/systemsont que des liens symboliques de services. Vous devez ajouter le *.servicefichier à /lib/systemd/systempartir duquel il sera lié /etc/systemd/systemsi vous enableutilisez le service. maskcrée un lien vers /dev/nullet unmasksupprime ce lien /etc/systemd/systemet évidemment cela ne fait aucune différence si quelqu'un y met un fichier.

— Kellerspeicher

3

hostname.serviceest masqué comme redondant car systemddéfinit le nom d'hôte (à partir de / etc / hostname) très tôt au démarrage.

Ce paramètre est fourni par le paquet Debian systemd.

$ 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

De même, Debian peut maintenant fonctionner sans script shell sur haltle système, il est géré par systemd-shutdown (le code source ici ).

Si un service a été masqué manuellement, le masque sera installé dans /etc/systemd/system place.

Les services sont également masqués lorsqu'ils sont supprimés sous Debian / Ubuntu . Je ne sais pas pourquoi

— sourcejedi
source

Le masquage ou la suppression de services entraîne une différence entre supprimer et purger un package. Dans le premier cas, les fichiers de configuration sont conservés et il peut donc être potentiellement dangereux d'activer un service par erreur (car le fichier de service peut encore se trouver dans les fichiers de configuration). Un package purgé aura également les fichiers de service supprimés et non masqués.

— Fiximan

0

Puisque vous demandez des informations sur l'état masqué, il est important de mentionner qu'il peut être observé dans un service qui, après avoir démarré, a modifié ses définitions, a rechargé (systemctl daemon-reload) et que le nouvel état n'est pas ok . Un exemple simple à comprendre est le scénario suivant:

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

Par conséquent, l'état masqué peut provenir d'une définition de service incorrecte. Par conséquent, l'utilisateur peut induire un état non masqué en modifiant le service de manière incorrecte.

Observation: je ne sais pas si cela se produit exprès ou s'il s'agit d'un simple bogue (option par défaut), mais il peut s'agir d'informations intéressantes à partager

— Thiago Conrado
source