Jak usunąć brakujące jednostki systemowe?

Mam problem z ustaleniem, jak usunąć jednostki systemowe, które nie mają już plików. Nadal wydają się utrzymywać jakoś w systemie.

Stare uszkodzone jednostki, które próbuję usunąć:

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

Pliki nie istnieją, ale przeładowanie nadal utrzymuje te jednostki:

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

Nie mogę znaleźć powiązanych z nimi plików:

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 ~ $

Jak więc się ich pozbyć?

systemd coreos

— Andy Shinn
źródło

Nie wspominasz o tym, ale myślę, że to się nie powiedzie, jeśli spróbujesz systemctl disable, prawda?

— dawud

Po prostu istnieje z 0. Nie ma nic do wyłączenia (już jej brakuje / wyłączono).

— Andy Shinn,

Wypróbowałem wszystkie rozwiązania zaproponowane tutaj (i do tej pory poniżej) i uruchomiłem ponownie i nic nie działało. Jednostki, które próbuję usunąć, były kiedyś instalowane lub próbowano zainstalować, a następnie zostały wyczyszczone. Więc najwyraźniej apt purge nie usuwa konfiguracji podanej systemd. Nadal nie jest dla mnie jasne, czy te „nie znalezione” jednostki powodują jakiekolwiek problemy.

— Widok eliptyczny

Podejrzewam, że mogę usunąć pliki w / var / lib / systemd / deb-systemd-helper-enabled /, ale nie jestem pewien, czy chcę z tym zadzierać. Wydaje mi się, że mam tam dwa znane ślepe zaułki: mariadb.service.dsh-also i mysql.service.dsh-also

— Widok eliptyczny

@Elipticalview Zrobić kopię zapasową tych plików, na wszelki wypadek, a następnie usunąć je?

— gf_

Odpowiedzi:

Polecenie, którego szukasz systemctl reset-failed

— użytkownik227117
źródło

Dziękuję Ci! Nie wiem, dlaczego nie było to dla mnie bardziej oczywiste ...

— Andy Shinn

To działało, by w końcu wyczyścić „prawdziwą” usługę, ale mam usługę aliasu, która nie chce odejść. Próbowałem disable, daemon-reloada reset-failedale obsługa alias wyjdzie jak not-found inactive deadzawsze. Przeszukałem również dysk w poszukiwaniu czegokolwiek, co pasuje do nazwy usługi bez żadnych wyników.

— Mark Lakata,

Właśnie na to wpadłem i systemctl stop <service>pracowałem dla siebie.

— mpontillo,

To samo odnosi się do timerów - muszą one zostać zatrzymany zanim reset-failedmożna je wyczyścić.

— rustyx

Niby pracował dla mnie, ale musiałem najpierw maskować, a potem zdemaskować dla jednego z nich. Ponadto musiałem zatrzymać jedną, a następnie maskować i zdemaskować, po czym resetowanie nie powiodło się w końcu pozbyłem się wszystkiego.

— tgunr

Kiedy systemd analizuje pliki definicji jednostek, bierze pod uwagę wszelkie inne powiązane jednostki wywoływane w pliku - niezależnie od tego, czy te inne jednostki istnieją, czy nie.

$ 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> )

Kiedy jednostka pojawia się jako „nie znaleziono”, niekoniecznie jest to błąd - wiemy tylko, że definicja lokalnej jednostki twierdzi, że ma z nią jakiś związek. Ten związek może nie być tym, na którym nam zależy. Na przykład może to być "Before:"inna jednostka, ale nie używamy tej innej jednostki.

— AaronDanielson
źródło

Wygląda na to, że systemd utrzymuje linki, ale nie wie, co z nimi zrobić po usunięciu pliku jednostki.

Możesz spróbować usunąć je ręcznie /etc/systemd/system/suspend.target.wants/i takie, ale oczywiście systemctl reset-failedz poprzedniej odpowiedzi brzmi jak lepsza opcja.

$ 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
źródło