web-dev-qa-db-fra.com

Comment supprimer les unités Systemd manquantes?

J'ai du mal à comprendre comment supprimer les unités systemd qui n'ont plus de fichiers. Ils semblent toujours s'attarder dans le système d'une manière ou d'une autre.

Les anciennes unités cassé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> [email protected] not-found failed failed [email protected]
<E2><97><8F> [email protected] not-found failed failed [email protected]

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 [email protected]
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> [email protected] not-found failed failed [email protected]
<E2><97><8F> [email protected] not-found failed failed [email protected]

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

Il n'y a aucun fichier qui leur soit lié que je puisse trouver:

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?

systemdcoreos
45
Andy Shinn

La commande que vous recherchez est systemctl reset-failed

80
user227117

Lorsque systemd analyse les fichiers de définition d'unité, il prend note de toutes les autres unités associées appelées dans le fichier, que ces autres 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 "introuvable", ce n'est pas nécessairement une erreur - tout ce que nous savons, c'est qu'une définition d'unité locale prétend avoir une relation avec elle. Cette relation pourrait ne pas nous intéresser. Par exemple, il peut s'agir de "Before:" une autre unité, mais nous n'utilisons pas cette autre unité.

2
AaronDanielson
  • failed - se produit lorsqu'une unité est entrée dans un état d'échec et peut être réinitialisée avec le systemctl reset-failed commande
  • not-found - se produit lorsque vous avez supprimé une unité mais que systemd a toujours une référence, comme lorsqu'une unité est activée et qu'un lien symbolique est placé dans /etc/systemd/system, cela peut être corrigé en supprimant les références à l'unité dans /etc/system/systemd/*.wants/ puis en cours d'exécution systemctl daemon-reload

Par exemple, supposez le script bash suivant:

#!/bin/bash
# script.sh
while true
do
    sleep 1
done

Et 3 unités systemd: example-foo.service, example-bar.service, et example-baz.service

$ Sudo systemctl cat example-{foo,bar,baz}.service
# /etc/systemd/system/example-foo.service
[Service]
ExecStart=/home/vagrant/script.sh
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/example-bar.service
[Service]
ExecStart=/home/vagrant/script.sh
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/example-baz.service
[Service]
ExecStart=/home/vagrant/script.sh
[Install]
WantedBy=multi-user.target

Maintenant, commençons et activons les unités. Observez comment les liens symboliques sont créés.

$ Sudo systemctl start example-{foo,bar,baz}.service
$ Sudo systemctl enable example-{foo,bar,baz}.service
Created symlink from /etc/systemd/system/multi-user.target.wants/example-foo.service to /etc/systemd/system/example-foo.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/example-bar.service to /etc/systemd/system/example-bar.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/example-baz.service to /etc/systemd/system/example-baz.service.

Confirmez qu'il y a bien 6 fichiers pour nos 3 unités.

$ find /etc/systemd/system -name 'example*.service'
/etc/systemd/system/multi-user.target.wants/example-bar.service
/etc/systemd/system/multi-user.target.wants/example-foo.service
/etc/systemd/system/multi-user.target.wants/example-baz.service
/etc/systemd/system/example-bar.service
/etc/systemd/system/example-foo.service
/etc/systemd/system/example-baz.service

Maintenant, vérifiez l'état des 3 unités, elles fonctionnent.

$ systemctl list-units example*
UNIT                LOAD   ACTIVE SUB     DESCRIPTION
example-bar.service loaded active running example-bar.service
example-baz.service loaded active running example-baz.service
example-foo.service loaded active running example-foo.service

Maintenant, simulez un échec en envoyant un SIGKILL à example-foo.service. Observez comment l'unité est en panne.

$ Sudo systemctl kill -s KILL example-foo.service
$ systemctl list-units example*
  UNIT                LOAD   ACTIVE SUB     DESCRIPTION
  example-bar.service loaded active running example-bar.service
  example-baz.service loaded active running example-baz.service
● example-foo.service loaded failed failed  example-foo.service

Pour réinitialiser une unité en panne, utilisez le systemctl rese-failed commande. Observez comment l'unité est maintenant dans un état inactif.

$ Sudo systemctl reset-failed
$ systemctl list-units example*
UNIT                LOAD   ACTIVE SUB     DESCRIPTION
example-bar.service loaded active running example-bar.service
example-baz.service loaded active running example-baz.service

...
$ systemctl list-units --all example*
UNIT                LOAD   ACTIVE   SUB     DESCRIPTION
example-bar.service loaded active   running example-bar.service
example-baz.service loaded active   running example-baz.service
example-foo.service loaded inactive dead    example-foo.service

D'accord, supprimons maintenant l'unité example-bar.service. Observez comment l'unité est dans un état introuvable; cependant, le lien symbolique cassé example-bar.service se trouve toujours dans /etc/system/system/multi-user.target.wants

$ Sudo rm /etc/systemd/system/example-bar.service
$ Sudo systemctl daemon-reload
$ Sudo systemctl stop example-bar.service
Failed to stop example-bar.service: Unit example-bar.service not loaded.
$ systemctl list-units --all example*
  UNIT                LOAD      ACTIVE   SUB     DESCRIPTION
● example-bar.service not-found inactive dead    example-bar.service
  example-baz.service loaded    active   running example-baz.service
  example-foo.service loaded    inactive dead    example-foo.service
$ find /etc/systemd/system -name 'example*.service'
/etc/systemd/system/multi-user.target.wants/example-bar.service
/etc/systemd/system/multi-user.target.wants/example-foo.service
/etc/systemd/system/multi-user.target.wants/example-baz.service
/etc/systemd/system/example-foo.service
/etc/systemd/system/example-baz.service

Supprimez le lien symbolique rompu et confirmez que l'unité example-bar.service a disparu.

$ Sudo rm /etc/systemd/system/multi-user.target.wants/example-bar.service
$ Sudo systemctl daemon-reload
$ systemctl list-units --all example*
UNIT                LOAD   ACTIVE   SUB     DESCRIPTION
example-baz.service loaded active   running example-baz.service
example-foo.service loaded inactive dead    example-foo.service
0
mbigras

Il semble que systemd conserve les liens mais ne sait pas quoi en faire lorsque vous supprimez le fichier d'unité.

Vous pouvez essayer de les supprimer manuellement dans /etc/systemd/system/suspend.target.wants/ et tel mais bien sûr systemctl reset-failed d'une réponse précédente sonne comme 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.
0
Rolf