Как удалить отсутствующие системные модули?

У меня проблемы с выяснением, как удалить системные модули, у которых больше нет файлов. Они все еще как-то задерживаются в системе.

Старые сломанные блоки, которые я пытаюсь удалить:

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

Файлы не существуют, но для перезагрузки все еще существуют следующие единицы:

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

Нет связанных с ними файлов, которые я могу найти:

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

Так как мне избавиться от них?

systemd coreos

— Энди Шинн
источник

Вы не упоминаете об этом, но я думаю, что это не удастся, если вы попробуете systemctl disableих, верно?

— Дауд

Он просто существует с 0. Ничего не нужно отключать (он уже отсутствует / отключен).

— Энди Шинн

Я перепробовал все решения, предложенные здесь (и ниже) и перезагрузил компьютер, и ничего не получалось. Модули, которые я пытаюсь удалить, были когда-то установлены или пытались установить, а затем были удалены. Таким образом, очевидно, что apt purge не удаляет конфигурацию, заданную для systemd. Мне все еще не ясно, вызывают ли эти "не найденные" единицы какие-либо проблемы.

— эллиптический вид

Я подозреваю, что могу удалить файлы из / var / lib / systemd / deb-systemd-helper-enabled /, но не уверен, что хочу с этим связываться. Похоже, у меня есть два известных тупика: mariadb.service.dsh-также и mysql.service.dsh-также

— эллиптическое представление

@Elipticalview Сделайте резервную копию этих файлов на всякий случай, а потом удалите их?

— gf_

Ответы:

Команда, которую вы ищете systemctl reset-failed

— user227117
источник

Спасибо! Я не знаю, почему это не было более очевидным для меня ...

— Энди Шинн

Это сработало для окончательной очистки «настоящей» службы, но у меня есть служба псевдонимов, которая отказывается уходить. Я попробовал disable, daemon-reloadи , reset-failedно служба псевдоним приходит , как not-found inactive deadвсегда. Я также искал на диске все, что соответствует названию службы, но безрезультатно.

— Марк Лаката

Я просто столкнулся с этим и systemctl stop <service>работал на меня.

— mpontillo

То же самое относится и к таймерам - их нужно сначала остановить, прежде чем reset-failedможно будет их очистить.

— rustyx

Вид работал для меня, но мне пришлось сначала замаскировать, а затем снять маску для одного из них. Также пришлось остановить один, затем замаскировать и снять маску, после чего сбросить-сбой окончательно избавился от всех.

— tgunr

Когда systemd анализирует файлы определения единиц, он принимает к сведению любые другие связанные единицы, вызванные в файле - независимо от того, существуют ли эти другие единицы или нет.

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

Когда юнит обнаруживается как «не найденный», это не обязательно ошибка - все, что мы знаем, это определение локального юнита, которое утверждает, что имеет с ним некоторую связь. Эти отношения могут быть не теми, о которых мы заботимся. Например, это может быть "Before:"какой-то другой блок, но мы не используем этот другой блок.

— AaronDanielson
источник

Кажется, что systemd поддерживает ссылки, но не знает, что с ними делать при удалении файла модуля.

Вы можете попытаться удалить их вручную /etc/systemd/system/suspend.target.wants/, но, конечно, systemctl reset-failedиз предыдущего ответа звучит как лучший вариант.

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

— Рольф
источник