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[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.
This output is misleading. Debian's /etc/init.d/rsync
was not starting rsync --daemon
, because I had not changed the default RSYNC_ENABLE=false
in /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 (/etc/systemd/system/rsync.service
-> /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.
Software versions
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.