Bug#879087: 'systemctl disable' on an enabled service which is an instance of a template unit fails !

denis.barbaron at orange.com denis.barbaron at orange.com
Thu Oct 19 08:22:57 BST 2017


Package: systemd
Version: 232-25+deb9u1

Imagine I have this template unit file /lib/systemd/system/foo at .service<mailto:/lib/systemd/system/foo at .service>
[Unit]
Description=hello service (%i)

[Service]
TimeoutStartSec=0
Type=oneshot
ExecStart=/bin/echo "hello world %i"

[Install]
WantedBy=multi-user.target
Alias=%p@%i.service<mailto:Alias=%25p@%25i.service>

Now, if I enabled two service instances from this template unit file, and I try to disable them just after then there is an error of type “Failed to disable unit: Too many levels of symbolic links”, and the only way to disable them properly is to disable the service template, look at the below example for a better understanding:

root at debian:/lib/systemd/system# systemctl enable hello at 1.service<mailto:hello at 1.service>
Created symlink /etc/systemd/system/hello at 1.service<mailto:/etc/systemd/system/hello at 1.service> → /lib/systemd/system/hello at .service<mailto:/lib/systemd/system/hello at .service>.
Created symlink /etc/systemd/system/multi-user.target.wants/hello at 1.service<mailto:/etc/systemd/system/multi-user.target.wants/hello at 1.service> → /lib/systemd/system/hello at .service<mailto:/lib/systemd/system/hello at .service>.

root at debian:/lib/systemd/system# systemctl enable hello at 2.service<mailto:hello at 2.service>
Created symlink /etc/systemd/system/hello at 2.service<mailto:/etc/systemd/system/hello at 2.service> → /lib/systemd/system/hello at .service<mailto:/lib/systemd/system/hello at .service>.
Created symlink /etc/systemd/system/multi-user.target.wants/hello at 2.service<mailto:/etc/systemd/system/multi-user.target.wants/hello at 2.service> → /lib/systemd/system/hello at .service<mailto:/lib/systemd/system/hello at .service>.

root at debian:/lib/systemd/system# systemctl disable hello at 1.service<mailto:hello at 1.service>
Failed to disable unit: Too many levels of symbolic links

root at debian:/lib/systemd/system# systemctl disable hello at 2.service<mailto:hello at 2.service>
Failed to disable unit: Too many levels of symbolic links

root at debian:/lib/systemd/system# systemctl disable hello at .service<mailto:hello at .service>
Removed /etc/systemd/system/hello at 1.service<mailto:/etc/systemd/system/hello at 1.service>.
Removed /etc/systemd/system/hello at 2.service<mailto:/etc/systemd/system/hello at 2.service>.
Removed /etc/systemd/system/multi-user.target.wants/hello at 1.service<mailto:/etc/systemd/system/multi-user.target.wants/hello at 1.service>.
Removed /etc/systemd/system/multi-user.target.wants/hello at 2.service<mailto:/etc/systemd/system/multi-user.target.wants/hello at 2.service>.

This is a big regression because on Jessie it works well, and as all my applications are based on systemd template unit files, I am not able actually to upgrade to Stretch…
I meet the same issue on x86_64 or ARM architecture.
The only work around I found is to manually remove symlink files but I don’t know if it is enough to properly disable a systemd service ?

Other technical informations:

-          dpkg -s libc6 | grep ^Version : Version: 2.24-11+deb9u1

-          uname -a : Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux








_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20171019/41e83730/attachment-0001.html>


More information about the Pkg-systemd-maintainers mailing list