Мне трудно понять, как удалить модули systemd, у которых больше нет файлов. Кажется, что они все еще как-то задерживаются в системе.
Старые сломанные блоки, которые я пытаюсь удалить:
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 ~ $
Итак, как мне избавиться от них?
Вам нужна команда systemctl reset-failed
Когда 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:"
какой-то другой блок, но мы его не используем.
Похоже, что 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.
failed
- происходит, когда устройство перешло в состояние отказа и может быть сброшено с помощью systemctl reset-failed
командаnot-found
- происходит, когда вы удалили модуль, но в systemd все еще есть ссылка на него, например, когда модуль включен и символическая ссылка помещается в /etc/systemd/system
, это можно исправить, удалив ссылки на модуль в /etc/system/systemd/*.wants/
затем бег systemctl daemon-reload
Например, предположим, что следующий сценарий bash:
#!/bin/bash
# script.sh
while true
do
sleep 1
done
И 3 модуля systemd: example-foo.service
, example-bar.service
, и 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
Теперь давайте запустим и включим блоки. Посмотрите, как создаются символические ссылки.
$ 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.
Подтвердите, что на самом деле есть 6 файлов для наших 3 единиц.
$ 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
Теперь проверьте состояние всех 3 блоков, они работают.
$ 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
Теперь смоделируйте сбой, отправив SIGKILL на example-foo.service
. Понаблюдайте, как устройство находится в неисправном состоянии.
$ 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
Чтобы сбросить блок в неисправном состоянии, используйте systemctl rese-failed
команда. Понаблюдайте за тем, как блок сейчас находится в неактивном состоянии.
$ 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
Хорошо, теперь давайте удалим модуль example-bar.service. Понаблюдайте, как объект находится в состоянии «не обнаружен»; однако неработающая символическая ссылка example-bar.service все еще находится в /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
Удалите неработающую символическую ссылку и убедитесь, что модуль example-bar.service исчез.
$ 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