Franck Bui
66a19d85a5
It might be needed to follow symlinks more deeply when we're looking for enablement symlinks pointing to the removed service. Let's consider the case where service 'old' is being renamed 'new' (will happen most likely during package upgrade). Before the service is going to be renamed, there's the following enablement symlink: /etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service In order to rename 'old' into 'new' and transparently restart the service, the old name is still provided as a 'static' alias for the new service. This should also help keeping backward compatibilities since the old name might still be embedded in unit files, scripts, generators and such. Hence after the package is upgraded, the following symlinks including the enablement symlink are present: /usr/lib/systemd/system/old.service -> new.service /etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service If later the user decides to disable the service, we should figure out that the enablement symlink (which still has the old name) is actually referring to 'new' (indirectly) even if it points to the alias.
System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.