[systemd-devel] disable/enable vs reenable

[Ross Lagerwall]

Hi,

If one executes:
$ sudo systemctl enable getty at tty1.service
ln -s '/usr/lib/systemd/system/getty at .service' '/etc/systemd/system/getty.target.wants/getty at tty1.service'

and then you decide to override getty at .service:
$ sudo cp /usr/lib/systemd/system/getty at .service /etc/systemd/system/getty at .service

the override does not work, as expected, because the symbolic link points to /usr..., not the
overridden service file:
$ ls -l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx 1 root root 38 Apr 18 08:41 getty at tty1.service -> /usr/lib/systemd/system/getty at .service

The documentation for reenable indicates that it should fix this problem:
 reenable NAME...
           Reenable one or more unit files, as specified on the command line. This is a combination
           of disable and enable and is useful to reset the symlinks a unit is enabled with to the
           defaults configured in the [Install] section of the unit file.

But it does not work:
$ sudo systemctl reenable getty at tty1.service
Failed to issue method call: File exists

However, disabling and enabling *does* work and gives the desired result:
$ sudo systemctl disable getty at tty1.service
rm '/etc/systemd/system/getty.target.wants/getty at tty1.service'
$ sudo systemctl enable getty at tty1.service
ln -s '/etc/systemd/system/getty at .service' '/etc/systemd/system/getty.target.wants/getty at tty1.service'

Is this a bug, a documentation problem or neither?

(using Arch Linux with systemd 201)

Regards
-- 
Ross Lagerwall