Je souhaite améliorer le temps de démarrage de mon Ubuntu GNOME 16.04 en désactivant les services de plymouth lors du démarrage. J'ai trouvé deux réponses sur la façon de le faire sur divers sites Web, à savoir:
# systemctl disable plymouth-quit-wait.service
# systemctl mask plymouth-quit-wait.service
Je ne peux exécuter aucune des actions ci-dessus à moins de savoir ce qu'elles font.
Si un service est enabled
, il existe un lien symbolique quelque part dans
/etc/systemd/system
dans un fichier unité, le plus souvent quelque part dans
/lib/systemd/system
De manière utile, lorsque vous enable
un service, les chemins complets du lien créé et de la cible seront imprimés sur la sortie standard.
La désactivation du service supprime le lien symbolique, de sorte que le fichier d'unité n'est pas affecté, mais le service n'est pas chargé au prochain démarrage, lorsque systemd lit /etc/systemd/system
.
Cependant, un service désactivé peut être chargé et sera démarré si un service qui en dépend est démarré ; enable
et disable
configurent uniquement le comportement de démarrage automatique pour les unités, et l'état est facilement remplacé.
Un service masqué en est un dont le fichier d'unité est un lien symbolique vers /dev/null
. Cela rend "impossible" le chargement du service, même s'il est requis par un autre service activé.
Lorsque vous mask
un service, un lien symbolique est créé de /etc/systemd/system
à /dev/null
, en laissant le fichier d'unité d'origine inchangé. Lorsque vous unmask
un service, le lien symbolique est supprimé.
Cependant, j'ai remarqué que ces commandes ne sont pas toujours honorées.
Lorsque j'essaie de masquer la plupart des services, cela échoue:
$ Sudo systemctl mask bluetooth.service
Failed to execute operation: Invalid argument
Bien sûr, j'ai arrêté le service en premier. @Anwar suggère que le masquage n'est possible que pour les services non critiques.
Démasquer un service masqué, à moins que je ne le masque moi-même, échoue également (en silence). Je pense car il n’existe aucun fichier d’unité pour le service, sauf sous la forme d’un lien symbolique vers /dev/null
, cette fois-ci en /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)
Je ne suis pas le seul à avoir ce problème
Pour démasquer le service masqué x11-common, j'ai dû supprimer le lien symbolique vers /dev/null
et Sudo apt-get install --reinstall x11-common && Sudo systemctl daemon-reload
. Maintenant, quand je l'interroge avec systemctl status x11-common
, je vois que le service a un cercle vert sympa et qu'il est chargé et actif (sorti) bien qu'il n'ait pas de fichier d'unité.
Pour plus de références, cet article sur Comment utiliser Systemctl peut être utile.
C'est assez simple.
systemctl start
, systemctl stop
: démarre (arrête) l'unité en question immédiatement ;systemctl enable
, systemctl disable
: marque (désélectionne) l'unité pour le démarrage automatique au démarrage (d'une manière spécifique à l'unité, décrite dans la section [Install]
);systemctl mask
, systemctl unmask
: interdit (permet) toutes les tentatives de démarrage de l'unité en question (manuellement ou en tant que dépendance de toute autre unité, y compris les dépendances de la cible de démarrage par défaut). Notez que le marquage pour le démarrage automatique dans systemd est implémenté en ajoutant une dépendance artificielle de la cible de démarrage par défaut à l'unité en question. Par conséquent, "masque" interdit également le démarrage automatique.Réf .: systemctl (1) .
Plus: Lennart Poettering (2011-03-02). "Les trois niveaux de désactivation" . systemd pour les administrateurs . 0pointer.de.
En bref,
disable
rend l'unité désactivée au démarrage. Mais cette unité peut être démarrée à tout moment après le démarrage.
mask
désactive complètement l'unité. Il ne peut être démarré sans démasquer. Cela implique automatiquement qu'il échouera au démarrage.