Hi, We noticed that our systems failed to boot correctly after upgrading from v242 to v260.2. I tracked it down to a semantic change introduced in PR #13119 (https://github.com/systemd/systemd/pull/13119, "Rework unit loading to take into account all aliases").
We use a symlink chain like this: /etc/systemd/system/default.target -> /etc/local/systemd_system_default.target -> /lib/systemd/system/multi-user.target The reason is that /etc is distributed and identical on all our systems, and the few exceptions are handled via symlinks. default.target is one such exception, for workstations it resolves to /lib/systemd/system/graphical.target instead. Before PR #13119, default.target became an alias of multi-user.target, so multi-user.target's dependencies were pulled in as expected. After the change this is no longer the case, because the first symlink's target (/etc/local/systemd_system_default.target) is not itself in a unit file search path, even though the final target is. As a result this is now what systemd.unit(5) calls a "linked unit file" rather than a "unit file alias", and dependencies of the eventually resolved unit are no longer honored. I wonder whether this change in semantics was intended. If not, would a PR be acceptable that changes the behavior so that a name is treated as an alias of the canonical unit (the last file in the chain that resides in a unit search path) as long as that name itself lives in a unit search path, even if an earlier or later hop in the chain temporarily leaves it? In the example above this would make default.target an alias of multi-user.target again, while the intermediate name in /etc/local, which is not in any unit search path, would still not become an alias itself. Thanks, Donald -- Donald Buczek [email protected] Tel: +49 30 8413 1433
