You can't use this approach for conky. These scripts are run before the GUI is loaded and before you log in. Your service is loaded and attempts to execute conky, which promptly exits because there are no available X screens.
This sort of thing should be done via the autorun settings of whatever desktop environment or window manager you are using. Many common desktop environments will run the program described by any .desktop
files in ~/.config/autostart
. For example, to run conky
create a file called ~/.config/autostart/conky.desktop
with the following contents:
[Desktop Entry]
Type=Application
Exec=/usr/bin/conky
X-GNOME-Autostart-enabled=true
NoDisplay=false
Hidden=false
Name[en_US]=conky
Comment[en_US]=
X-GNOME-Autostart-Delay=0
Is there documentation for this behaviour?
It is written down. The pointer as to why this is implemented is found in a commit message to a file which was since moved elsewhere...
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?
Look hard, and you can still find the source history. It links to an issue, which confirms that masking is used to handle the system V initscripts as best as possible under systemd.
Tangent: there's an unimplemented proposal which would remove the need for this, #749400 - dh_installinit: disable init scripts on removal of package. Not that it's an unambiguously good idea. IIUC, it loses track of whether the script was enabled by the user. (Note this is a separate setting for each runlevel, in system V init).
The clue to this was in the package script, which I found at /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
What this does is documented in man deb-systemd-helper
. 'The "mask" action will keep state on whether the service was enabled/disabled before and will properly return to that state on "unmask".' It is also commented in 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 (version 25) doesn't implement this behaviour. Arguably because they don't support system V init and had a policy to completely remove the old-style init scripts. I don't know how they handled this issue during the transition... but they could have ignored it without causing any functional problem.
What is the conflict that causes systemd to warn, when faced with this behaviour of Debian?
In the general case, masking an enabled service seems a bit suspicious, perhaps?
It looks like the rpm based distributions don't / didn't try to preserve the enabled status of initscripts. Because they run checkconf --del
on removal. https://www.cyberciti.biz/faq/centos-rhel-suse-rpm-see-installation-uninstallation-scripts/
The modern Fedora rpms have equivalent-looking code
$ rpm -q --scripts rsync
...
# Package removal, not upgrade
systemctl --no-reload disable --now avahi-daemon.socket avahi-daemon.service > /dev/null 2>&1 || :
...
I looked at this as I noticed removing rsync-daemon doesn't remove /etc/systemd/system/multi-user.target.wants/rsyncd.service
. Because systemctl disable
does not currently remove symlinks if they point to a file which has already been removed. This is a bug specific to the rsync package: the service file is in package rsync
, but the rpm scripts referring to the service are in package rsync-daemon
.
Best Answer
it's not possible. This feature was implemented for the .rules-variant only
https://github.com/systemd/systemd/pull/1159