Comment supprimer les unités systemd manquantes?

Je n'arrive pas à comprendre comment supprimer les unités systemd qui ne possèdent plus de fichiers. Ils semblent toujours s'attarder dans le système.

Les anciennes unités brisées que j'essaie de supprimer:

core@ip-172-16-32-83 ~ $ systemctl list-units --all firehose-router*
  UNIT                       LOAD      ACTIVE SUB    DESCRIPTION
<E2><97><8F> firehose-router@02.service not-found failed failed firehose-router@02.service
<E2><97><8F> firehose-router@03.service not-found failed failed firehose-router@03.service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

Les fichiers n’existent pas, mais un rechargement a toujours ces unités en attente:

core@ip-172-16-32-83 ~ $ systemctl list-unit-files firehose-router@02.service
core@ip-172-16-32-83 ~ $ sudo systemctl daemon-reload
core@ip-172-16-32-83 ~ $ systemctl list-units --all firehose-router*
  UNIT                       LOAD      ACTIVE SUB    DESCRIPTION
<E2><97><8F> firehose-router@02.service not-found failed failed firehose-router@02.service
<E2><97><8F> firehose-router@03.service not-found failed failed firehose-router@03.service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

Je ne peux trouver aucun fichier lié à ces fichiers:

core@ip-172-16-32-83 ~ $ sudo find /var/run/systemd -name "*firehose-router*"
core@ip-172-16-32-83 ~ $ find /etc/systemd/ -name "*firehose-router*"
core@ip-172-16-32-83 ~ $ find /usr/lib/systemd/ -name "*firehose-router*"
core@ip-172-16-32-83 ~ $

Alors, comment puis-je m'en débarrasser?

systemd coreos

— Andy Shinn
source

Vous n'en parlez pas, mais j'imagine que cela échoue si vous essayez systemctl disable, non?

— Dawud

Il existe juste avec 0. Il n'y a rien à désactiver (il est déjà manquant / désactivé).

— Andy Shinn

J'ai essayé toutes les solutions suggérées ici (et ci-dessous jusqu'à présent) et redémarré et rien n'a fonctionné. Les unités que je tente de supprimer ont été installées une fois ou ont tenté de l'être, puis ont été purgées ultérieurement. Donc, apparemment, apt purge ne supprime pas la configuration donnée à systemd. Ce n'est toujours pas clair pour moi si ces unités "non trouvées" causent des problèmes.

— Vue elliptique le

Je suppose que je pourrais peut-être supprimer des fichiers de / var / lib / systemd / deb-systemd-helper-enabled /, mais je ne suis pas sûr de vouloir jouer avec cela. Je semble y avoir deux impasses connues: mariadb.service.dsh-also et mysql.service.dsh-also

— Vue elliptique

@Elipticalview Faites une sauvegarde de ces fichiers, au cas où, puis supprimez-les?

— gf_

Réponses:

La commande que vous recherchez est systemctl reset-failed

— utilisateur227117
source

Merci! Je ne sais pas pourquoi ce n'était pas plus évident pour moi ...

— Andy Shinn le

Cela a fonctionné pour finalement nettoyer un "vrai" service, mais j'ai un service de pseudonyme qui refuse de partir. J'ai essayé disable, daemon-reloadet reset-failedmais le service d'alias qui se présente comme not-found inactive deadtoujours. J'ai également recherché sur le disque tout ce qui correspond au nom du service sans résultat.

— Mark Lakata

Je viens de rencontrer sur cette question et systemctl stop <service>a fonctionné pour moi.

— Mpontillo

Il en va de même pour les minuteries: elles doivent être arrêtées avant de reset-failedpouvoir les nettoyer.

— Rustyx

Ça a fonctionné pour moi, mais je devais masquer puis démasquer d'abord l'un d'entre eux. De plus, il a fallu arrêter un masque puis un démasquage, après quoi reset-failed a finalement été débarrassé de tout.

— tgunr

Lorsque systemd analyse les fichiers de définition d'unité, il prend note de toute autre unité associée appelée dans le fichier, que ces unités existent ou non.

$ systemctl --state=not-found --all
> ( ...prints list of 'not-found' units )

$ grep -r "<missing-unit>" /usr/lib/systemd/system
> ( returns files with references to <missing-unit> )

Lorsqu'une unité apparaît comme "non trouvée", ce n'est pas nécessairement une erreur - tout ce que nous savons, c'est qu'une définition d'une unité locale prétend avoir une relation avec elle. Cette relation pourrait ne pas nous intéresser. Par exemple, il pourrait s'agir d' "Before:"une autre unité, mais nous n'utilisons pas cette autre unité.

— AaronDanielson
source

Il semblerait que systemd maintienne les liens mais ne sache pas quoi en faire lorsque vous supprimez le fichier unité.

Vous pouvez essayer de les supprimer manuellement /etc/systemd/system/suspend.target.wants/, mais systemctl reset-failedune réponse précédente semble bien sûr être une meilleure option.

$ cd /etc/systemd/system
$ sudo mv lock.service /tmp 
$ sudo systemctl disable lock.service
Failed to disable unit: No such file or directory
$ sudo mv /tmp/lock.service .
$ sudo systemctl disable lock.service
Removed /etc/systemd/system/suspend.target.wants/lock.service.

— Rolf
source