I booted a Debian unstable container. Early on, systemd inside the container shows
rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked.
I determined that rsync.service was masked automatically because the rsync package was removed. Re-installing the package unmasked it again.
- Is there documentation for this behaviour?
- What is the conflict that causes systemd to warn, when faced with this behaviour of Debian?
- 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?
Discovery of automatic masking on package removal
I knew that rsync had originally been installed, but was now removed. I removed the mask, and was left with this:
$ 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: Starting LSB: fast remote file copy program daemon... Jun 07 11:35:27 unstable systemd: Started LSB: fast remote file copy program daemon.
This output is misleading. Debian's
/etc/init.d/rsync was not starting
rsync --daemon, because I had not changed the default
/etc/default/rsync. (The init script itself would exit silently in this case; however I believe a systemd boot would show a starting message for it, similar to the log messages shown above). So the masking was serving a useful purpose here.
(The reason /etc/init.d/rsync remains when the package is removed, is that initscripts are considered to be user-editable configuration files)
It turns out that if I install rsync again, rsync.service is unmasked. If I remove it, rsync.service becomes masked again.
I'm pleased to say that if I install rsync, mask it, then remove and reinstall rsync, rsync remains masked.
If I use
apt-get remove --purge rsync to completely remove it, including residual configuration files, then the mask is removed.
Since I have etckeeper installed, I noticed that complete removal also removes
/etc/systemd/system/multi-user.target.wants/rsync.service, as well as removing the mask (
/dev/null). Neither of these files were owned by the package (
dpkg-query -L rsync), so it looks like these removals are caused by a package script.
Up to date Debian unstable container. This question was asked soon before the release of stretch.
Host used systemd-container version 231-15.fc25.
More context for systemd message "ignoring: Unit rsync.service is masked"
$ 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.