fd22838734
We had the following scenario: under /etc/systemd/system/ - foo@.service - bar@tty12.service → foo@tty12.service - multi-user.target.wants/foo@tty12.service Existing code did not "know" that foo@tty12.service has alias bar@tty12.service: $ systemctl show -P Names foo@tty12.service foo@tty12.service Since multi-user.target is always loaded, we would load foo@tty12.service. When trying to load bar@tty12.service, it would (correctly) detect that bar@tty12.service is an alias for foo@tty12.service, and try to merge the bar@tty12.service unit into the foo@tty12.service. This would fail, because foo@tty12.service was already loaded, and only about-to-be-loaded units can be merged. With the patch we consider bar@tty12.service an alias of foo@tty12.service immediately, so the issue does not occur: $ systemctl show -P Names foo@tty12.service foo@tty12.service bar@tty12.service Fixes #19409. This turned in a bigger rewrite. The logic add "the main name and all aliases" was implemented twice, slightly different in both cases. I split that part out to a new function. The result about the same length, but hopefully a bit easier to read. Logging output is also improved a bit. Some left-over debug logs have been removed or cleaned up. This is a fairly big change, but (with the addition in the following commit), we have pretty good coverage of this logic.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, 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.