[systemd-devel] Antw: Re: Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot

[Ulrich Windl]

>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 24.10.2022 um 10:26 in
Nachricht
<CAA91j0W3t5a-1MNPaehRhG3DuBYU0eJLpL3X0jvMvpDFsRb3FQ at mail.gmail.com>:
> On Mon, Oct 24, 2022 at 9:48 AM Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
>>
>> >>> Alex Aminoff <aminoff at nber.org> schrieb am 21.10.2022 um 18:11 in Nachricht
>> <c6daef42-ee08-0293-e198-8362691a3185 at nber.org>:
>>
>> ...
>> > Just to close out this thread, I am happy to report that
>> >
>> > ExecStart=systemctl start --no-block multi-user.target
>> >
>> > worked great.
>>
>> Makes me wonder: How does systemd handle indirect recursive starts (like the 
> one shown)?
>>
> 
> What do you call a "recursive start"? "systemctl start" simply tells

starting multi-user.target via ExecStart=systemctl start starts all depending units, and probably one of those starts the multi-user.target again.
That's what I call recursive.

> systemd to queue the start job. If this job is already queued, nothing
> happens. If this job has already been completed (successfully),
> nothing happens.

So I wonder why the command "ExecStart=systemctl start --no-block multi-user.target" has any effect then.

> 
> Where recursion come from?

See above.