Удаление пакета Debian автоматически маскирует службу systemd – вызывает предупреждение systemd

Я загрузил нестабильный контейнер Debian. На ранней стадии systemd внутри контейнера показывает rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked .

Я решил, что rsync.service автоматически маскируется, потому что пакет rsync был удален. Повторная установка пакета снова разоблачила его.

  • Есть ли hpdarm -Y, чтобы остановить IO на моем жестком диске?
  • Samba Поделиться: Вход для гостей не работает после Wheezy -> Jessie
  • Условные зависимости для пакета Debian
  • Что означает ~ / .config и как туда помещать файлы?
  • Как обеспечить исключительную доступность процессора для текущего процесса?
  • Очень медленный SW-RAID 5 в Debian Squeeze
    1. Есть ли документация для этого поведения?
    2. Каков конфликт, который заставляет systemd предупреждать, сталкиваясь с таким поведением Debian?
    3. Я очень удивлен, увидев, что это поведение каким-то образом обнаруживает, что я замаскировал rsync во время его установки и избегает его разоблачения автоматически, если я удалю и переустановить rsync. Как это реализовано? Есть ли какие-то более тонкие ограничения?

    Открытие автоматической маскировки при удалении упаковки

    Я знал, что rsync изначально был установлен, но теперь был удален. Я удалил маску и остался с этим:

     $ sudo systemctl status rsync ● rsync.service - LSB: fast remote file copy program daemon Loaded: loaded (/etc/init.d/rsync; generated; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) $ # reset status of all systemd services $ # DO NOT TRY THIS COMMAND INSIDE A REAL, NON-CONTAINER SYSTEM... $ # IT DOES NOT GO WELL. $ sudo systemctl isolate default.target $ sudo systemctl status rsync ● rsync.service - LSB: fast remote file copy program daemon Loaded: loaded (/etc/init.d/rsync; generated; vendor preset: enabled) Active: active (exited) since Wed 2017-06-07 11:35:27 BST; 1s ago Docs: man:systemd-sysv-generator(8) Process: 432 ExecStart=/etc/init.d/rsync start (code=exited, status=0/SUCCESS) CGroup: /machine.slice/machine-unstable.scope/system.slice/rsync.service Jun 07 11:35:27 unstable systemd[1]: Starting LSB: fast remote file copy program daemon... Jun 07 11:35:27 unstable systemd[1]: Started LSB: fast remote file copy program daemon. 

    Этот вывод вводит в заблуждение. В rsync --daemon /etc/init.d/rsync Debian не rsync --daemon , потому что я не изменил значение по умолчанию RSYNC_ENABLE=false в /etc/default/rsync . (В этом случае сам скрипт инициализации выйдет без звука, однако я считаю, что системная загрузка будет показывать для него стартовое сообщение, подобное сообщениям журнала, показанным выше). Таким образом, маскировка служила полезной цели здесь.

    (Причина, по которой /etc/init.d/rsync остается, когда пакет удален, заключается в том, что initscripts считаются редактируемыми пользователем файлами конфигурации)

    Оказывается, если я снова установлю rsync, rsync.service будет разоблачен. Если я удалю его, rsync.service снова замаскируется.

    Я рад сказать, что если я установлю rsync, замаскирую его, то удалите и переустановите rsync, rsync останется в маске.

    Если я использую apt-get remove --purge rsync чтобы полностью удалить его, включая остаточные файлы конфигурации, затем маску удалить.

    Поскольку у меня установлен etckeeper, я заметил, что полное удаление также удаляет /etc/systemd/system/multi-user.target.wants/rsync.service , а также удаление маски ( /etc/systemd/system/rsync.service – > /dev/null ). Ни один из этих файлов не принадлежал пакету ( dpkg-query -L rsync ), поэтому похоже, что эти удаления вызваны сценарием пакета.

    Версия программного обеспечения

    Обновлен нестабильный контейнер Debian. Этот вопрос был задан вскоре перед выпуском растяжки.

    Хост использовал systemd-контейнер версии 231-15.fc25.

    Больше контекста для сообщения systemd "игнорирование: Unit rsync.service замаскирован"

     $ sudo systemd-nspawn -b -D unstable Spawning container unstable on /home/nspawn/unstable. Press ^] three times within 1s to kill container. systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to Debian GNU/Linux 9 (stretch)! Set hostname to <unstable>. Failed to install release agent, ignoring: File exists rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked [ OK ] Started Dispatch Password Requests to Console Directory Watch. 

  • прекратить поиск srv записей
  • Как узнать, в каком порядке загружаются скрипты /etc/init.d на Debian?
  • Предупреждение о том, что addgroup пытается создать уже существующую группу пользователей
  • Mutter и Intel GMA 4500MHD
  • Наследование переменных среды в systemd Контейнер докеров
  • Apache «Модуль mod_alias не существует»
  • One Solution collect form web for “Удаление пакета Debian автоматически маскирует службу systemd – вызывает предупреждение systemd”

    Есть ли документация для этого поведения?

    Это записано. Указатель относительно того, почему это реализовано, находится в сообщении о фиксации файла, который был перенесен в другое место …

    Я очень удивлен, увидев, что это поведение каким-то образом обнаруживает, что я замаскировал rsync во время его установки и избегает его разоблачения автоматически, если я удалю и переустановить rsync. Как это реализовано? Есть ли какие-то более тонкие ограничения?

    Посмотрите внимательно, и вы все равно можете найти исходную историю . Он ссылается на проблему , которая подтверждает, что маскирование используется для максимально эффективного управления системой V initscripts в systemd.

    Tangent: есть нереализованное предложение, которое устранит необходимость в этом, # 749400 – dh_installinit: отключить скрипты init при удалении пакета . Не то, чтобы это была однозначно хорошая идея. IIUC, он теряет контроль над тем, был ли сценарий включен пользователем. (Обратите внимание, что это отдельная настройка для каждого уровня запуска, в системе V init).

    Ключ к этому был в сценарии пакета, который я нашел в /var/lib/dpkg/info/rsync.postrm .

     ## from /usr/share/debhelper/autoscripts/postrm-systemd : if [ "$1" = "remove" ]; then if [ -x "/usr/bin/deb-systemd-helper" ]; then deb-systemd-helper mask rsync.service >/dev/null fi fi 

    То, что это делает, описано в man deb-systemd-helper . «Действие« Маска »будет содержать информацию о том, была ли служба включена / отключена раньше и будет правильно возвращена в это состояние на« unmask ». ' Он также комментируется в rsync.postinst :

     ## from /usr/share/debhelper/autoscripts/postinst-systemd-enable : # This will only remove masks created by dsh on package removal. deb-systemd-helper unmask rsync.service >/dev/null || true 

    Fedora Linux (версия 25) не реализует это поведение. Возможно, потому, что они не поддерживают систему V init и имеют политику для полного удаления сценариев инициализации в старом стиле. Я не знаю, как они справились с этой проблемой во время перехода … но они могли игнорировать ее, не вызывая никаких функциональных проблем.

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

    В общем случае маскировка включенной службы кажется немного подозрительной, может быть?

    Похоже, что дистрибутивы на основе rpm не пытаются / не пытались сохранить разрешенный статус initscripts. Потому что они запускают checkconf --del при удалении. https://www.cyberciti.biz/faq/centos-rhel-suse-rpm-see-installation-uninstallation-scripts/


    Современные процессоры Fedora имеют эквивалентный код

     $ rpm -q --scripts rsync ... # Package removal, not upgrade systemctl --no-reload disable --now avahi-daemon.socket avahi-daemon.service > /dev/null 2>&1 || : ... 

    Я посмотрел на это, поскольку заметил, что удаление rsync-daemon не удаляет /etc/systemd/system/multi-user.target.wants/rsyncd.service . Поскольку systemctl disable настоящее время не удаляет символические ссылки, если они указывают на файл, который уже удален. Это ошибка, характерная для пакета rsync: файл службы находится в пакете rsync , но сценарии rpm, ссылающиеся на службу, находятся в пакете rsync-daemon .

    Linux и Unix - лучшая ОС в мире.