systemctl, comment démasquer

root@gcomputer:~# systemctl status x11-common
● x11-common.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

J'ai essayé systemctl unmask x11-commonet systemctl unmask x11-common.servicecela n'a rien changé.

Comment le démasquer?

systemd

— Albert
source

Les commandes que vous utilisez sont toutes les deux correctes . Voir aussi le manuel .

Il semble que la unmaskcommande échoue lorsqu'il n'y a aucun fichier d'unité dans le système autre que le lien symbolique vers /dev/null. Si vous maskun service, puis qui crée un nouveau lien symbolique /dev/nulldans /etc/systemd/systemlequel les regards systemd pour les fichiers de l' unité à charger au démarrage. Dans ce cas, il n'y a pas de véritable fichier unitaire.

D'autres semblent avoir des problèmes similaires

x11-common.servicea également été masqué sur mon système. Vous pouvez le réparer comme ceci:

Vérifiez d'abord que le fichier d'unité est un lien symbolique vers /dev/null

file /lib/systemd/system/x11-common.service

il devrait retourner:

/lib/systemd/system/x11-common.service: symbolic link to /dev/null

dans ce cas, supprimez-le

sudo rm /lib/systemd/system/x11-common.service

Puisque vous avez modifié un fichier d'unité, vous devez exécuter ceci:

sudo systemctl daemon-reload

vérifiez maintenant le statut:

systemctl status x11-common

s'il ne dit pas chargé et en cours d'exécution (si le cercle est toujours rouge), réinstallez le package:

sudo apt-get install --reinstall x11-common

et recharger à nouveau le démon

sudo systemctl daemon-reload

et vérifier à nouveau le statut

systemctl status x11-common

Maintenant, il est vert et fonctionne :) Le service n'a pas de fichier d'unité systemd, mais systemd utilise volontiers le script pour cela /etc/init.d.

— Zanna
source

Ok, question complémentaire: s'il était même masqué sur votre système, à quoi sert ce service? Il semble que ce ne soit pas vraiment nécessaire s'il est masqué pour nous deux.

— Albert

@Albert [Voir ici.] ( Askubuntu.com/questions/712276/… ) semble que le service fonctionne sans le fichier d'unité systemd (il a un fichier dans /etc/init/...). Vous voudrez peut-être poser une nouvelle question. Ce que j'ai fait n'a fait aucune différence apparente, seul le service s'affiche comme chargé, activé, arrêté (il est actif au démarrage) (vert) au lieu de chargé masqué mort (rouge). Je devrais lire mes journaux ...

— Zanna

si une mise à jour pour systemd arrive, le fichier d'unité est réinstallé, donc ce n'est pas vraiment une solution structurelle

— hbogert

@hbogert est-ce que cela se produit même s'il n'y avait pas de fichier unité en dehors du lien symbolique vers /dev/null? Mais vous avez raison sur ma réponse. J'appellerais cette solution une solution de contournement pour un ... comportement déroutant ... de systemd

— Zanna

Pourriez-vous décrire votre première phrase en termes de fichiers exacts qui importent dans ce cas (parce que je ne comprends pas vraiment le scénario que vous décrivez)?

— hbogert

Il se peut que votre service ait un fichier de remplacement vide, comme ceci:

● redis-server.service - Magasin de valeurs-clés avancé Chargé: chargé (/lib/systemd/system/redis-server.service; masqué; prédéfini par le fournisseur: activé) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Vérifiez si limit.conf est un fichier vide. Si c'est le cas, veuillez le retirer. Ensuite, le service doit être démasqué.

— Erik Hensema
source

Suivez les étapes ci-dessous:

systemctl edit systemd-hostnamed

Ajoutez les 2 lignes ci-dessous puis quittez l'éditeur (n'oubliez pas d'enregistrer lorsque vous y êtes invité):
```
[Service]
PrivateNetwork=no
```
Cela va créer un fichier override.conf avec les 2 lignes ci-dessus dans le répertoire:
```
/etc/systemd/system/systemd-hostnamed.service.d/
```
La mise à jour systemd:
```
systemctl daemon-reload
```
Redémarrez ensuite le service:
```
systemctl restart systemd-hostnamed
```

Vous devriez maintenant pouvoir courir hostnamectlsans le suspendre.

— Hossein
source