Si j'installe un nouveau service puis décide que je ne veux plus de cette application et que je la supprime, le service est toujours répertorié dans la sortie de systemctl comme erreur.
D'où vient cela et comment puis-je les supprimer complètement?
Ma recette pour l'oblitération du service (faites attention aux instructions rm!)
systemctl stop [nom du service]
systemctl disable [nom du service]
rm /etc/systemd/system/[nom du service]
rm /etc/systemd/system/[nom du service] # et les liens symboliques qui pourraient être liés
rm /usr/lib/systemd/system/[nom du service]
rm /usr/lib/systemd/system/[nom du service] # et les liens symboliques qui pourraient être liés
systemctl daemon-reload
systemctl reset-failedIl est possible que le service systemd 'enveloppe' les anciens scripts situés dans /etc/init.d, donc vous voudrez peut-être nettoyer cela aussi, mais ce n'est pas là où résident les services systemd.
Sachez qu'il existe plusieurs emplacements où les fichiers d'unité Systemd sont stockés, notamment /usr/lib/systemd/system et aussi /etc/systemd/system/. Pour plus d'informations, consultez: access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
J'ai également dû supprimer /etc/init.d/[servicename] avant d'exécuter systemctl reset-failed
À droite, j'ai oublié de désactiver avant de supprimer les fichiers d'unité. Au fait, pour trouver tous les fichiers d'unité à supprimer, j'inspecte la sortie de systemctl cat [nomduservice].
Vous cherchez probablement reset-failed :
$ sudo systemctl reset-failed
$Depuis la page de manuel de systemd :
reset-failed [PATTERN...]Réinitialise l'état "échoué" des unités spécifiées, ou si aucun nom d'unité n'est passé, réinitialise l'état de toutes les unités. Lorsqu'une unité échoue de quelque manière que ce soit (c'est-à-dire, un processus se termine avec un code d'erreur différent de zéro, se termine de manière anormale ou dépasse le délai imparti), elle entrera automatiquement dans l'état "échoué" et son code de sortie et son statut seront enregistrés pour inspection par l'administrateur jusqu'à ce que le service soit redémarré ou réinitialisé avec cette commande.
Ce n'est pas du tout ce que la question demande. Pourquoi diable cela a-t-il été voté positivement 17 fois ?
Ceci est la seule réponse correcte. Les autres avec plus de votes et la coche sont des solutions de contournement.
Ajoutant à la réponse de @mark-lakata et en gardant à l'esprit l'attention requise pour la commande rm. [chkconfig] peut simplifier le processus! (Cliquez ici pour en savoir plus sur chkconfig)
Pour réitérer la liste des commandes:
systemctl stop [nomduservice]chkconfig [nomduservice] off OU pour les systèmes plus récents systemctl disable [nomduservice]systemctl daemon-reloadsystemctl reset-failedRemarque: La 1ère commande est facultative selon que vous souhaitez conserver le service en cours d'exécution dans la session actuelle ou non (pour cette question, la commande devrait être utilisée).
La 2ème commande s'occupe à la fois de la désactivation et de la suppression (en suivant les liens symboliques) du service.
chkconfig était la commande originale pour activer/désactiver les services SysVinit. Dans les systèmes utilisant systemd, elle peut exister en tant que commande de compatibilité ascendante; mais la commande native systemctl est tout aussi simple: systemctl disable [servicename]
D'accord, mais la raison pour laquelle j'utilise cette commande est que vous n'avez pas à exécuter explicitement la commande rm
Suppression d'un service de systemd :
Systemd utilise des unités (fichiers pour définir des services) pour supprimer un service, l'unité doit être supprimée... voici une liste des emplacements des unités :
/etc/systemd/system/ (et sous-répertoires)
/usr/local/etc/systemd/system/ (et sous-répertoires)
~/.config/systemd/user/ (et sous-répertoires)
/usr/lib/systemd/ (et sous-répertoires)
/usr/local/lib/systemd/ (et sous-répertoires)
/etc/init.d/ (système de services ancien converti)Actualiser systemd :
systemctl daemon-reload
systemctl reset-failedServices fantômes (non trouvés) :
Systemd peut lister des services fantômes (non trouvés) même si l'unité est supprimée pour de nombreuses raisons
(*) si un service est mentionné dans d'autres unités mais n'existe pas, systemd listera toujours ce service avec l'état non trouvé même s'il n'y a pas de fichier unité... vous pouvez rechercher quelle unité utilise ce service avec une recherche de texte et modifier ces unités (non recommandé si vous prévoyez d'installer ce service ultérieurement)
Sources : Linuxhacks.org
Divulgation : Je suis le propriétaire de Linuxhacks.org
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
