[systemd-devel] default.target and external symlinks

[Andrei Borzenkov]

23.12.2020 18:28, Alexander Sbitnev пишет:
>   Hi there!
>   I am trying to use upcoming Debian 11 Bullseye with read-only root
> filesystem.
> And I discovered SystemD behaviour change compared to Debian 9. It is not
> related to read-only root by itself and can be easily reproduced with a
> normal installation.
> With new Debian 11 SystemD (247.1-3) it is not possible to use chain of
> symlinks from /etc/systemd/system/default.target to choose target if chain
> include elements outside of SystemD directories (/etc/systemd/system/ or
> /lib/systemd/system/).
> For example next chain work fine:
> /etc/systemd/system/default.target -> default.redirect.target ->
> /lib/systemd/system/default.test.target ->
> /lib/systemd/system/multi-user.target
> 
> And if I move default.redirect.target from /etc/systemd/system/ to /etc/
> system will not boot correctly. Problematic chain looks next way:
> /etc/systemd/system/default.target -> /etc/default.redirect.target ->
> /lib/systemd/system/multi-user.target
> 
> Chain by itself looks valid:
> root at deb11tiny:/etc/systemd/system# cat /etc/systemd/system/default.target
> #  SPDX-License-Identifier: LGPL-2.1-or-later
> #
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
> 
> [Unit]
> Description=Multi-User System
> Documentation=man:systemd.special(7)
> Requires=basic.target
> Conflicts=rescue.service rescue.target
> After=basic.target rescue.service rescue.target
> AllowIsolate=yes
> 
> root at deb11tiny:/etc/systemd/system# systemctl get-default
> multi-user.target
> 
> And system actually booting. And SystemD seems to know which target it
> should boot as I can see in output next lines:
> ...
> [    4.508581] systemd[1]: Queued start job for default target Multi-User
> System.
> ...
> [  OK  ] Reached target Multi-User System.
> 
> But the booted system will get most of its units inactive. Network, sshd...
> even gettys stays unstarted.
> Is it a problem with Debian SystemD build? Or is it correct behaviour?
> 

The fact that systemd does not alias default.target to multi-user.target
is likely intentional, judging by comment in
src/shared/unit-file.c:unit_file_build_name_map()

                                /* Check if the symlink goes outside of
our search path.
                                 * If yes, it's a linked unit file or
mask, and we don't care about the target name.
                                 * Let's just store the link destination
directly.
                                 * If not, let's verify that it's a good
symlink. */

So systemd loads *content* of default.target which is valid unit
definition and proceeds, but because default.target is not associated
with  multi-user.target it does not pull in all multi-user.tagret
dependencies.

In this case systemctl get-default returning multi-user.target is a bug.
It must follow the the same rules and use the same unit cache (at least,
it must behave as if it is using the same unit cache). Currently it
chases symlinks which was also historical systemd behavior. This
probably explains why it works for you in the past.


> If this behaviour is unexpected I can supply any additional info but I
> don't know there to put it. Should I open a new bug in Debian tracker and
> put it there or can I just share it from cloud storage and supply a link to
> this list?
> 

Open issue on systemd tracker.

> Another interesting note to add: manually adding
> "systemd.unit=multi-user.target" to boot params allows the system to boot
> normal. So it definitely looks like a bug to me.
> 


Yes, because in this case systemd also starts all dependencies on
multi-user.tagret (i.e. most of "enabled" units).