Невозможно назначить вывод команды переменной

Is there documentation for this behaviour?

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

I'm pleasantly surprised to see that this behaviour somehow detects if I masked rsync while it was installed, and avoids unmasking it automatically if I remove and reinstall rsync. How is this implemented?? Are there any more subtle limitations to it?

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

Tangent :есть нереализованное предложение, которое устранило бы необходимость в этом,#749400 -dh _installinit :отключить сценарии инициализации при удалении пакета . Не то чтобы это однозначно хорошая идея. 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. «Действие «маска» будет сохранять состояние о том, была ли служба ранее включена/отключена, и будет должным образом возвращаться в это состояние при «снятии маски».» Это также прокомментировано вrsync.postinst:

## from /usr/share/debhelper/autoscripts/postinst-systemd-enable :

# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask rsync.service >/dev/null || true

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

What is the conflict that causes systemd to warn, when faced with this behaviour of Debian?

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

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

---

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