Re: [systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mon, Oct 24, 2022 at 1:24 PM Ulrich Windl wrote: > > > > > 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. > Because it also recursively queues start jobs for all Want'ed or Require'd units even if multi-user.target itself is already started. This allows you to catch up on new dependencies.
Re: [systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mon, Oct 24, 2022 at 9:48 AM Ulrich Windl wrote: > > >>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in > >>> Nachricht > : > > ... > > 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 systemd to queue the start job. If this job is already queued, nothing happens. If this job has already been completed (successfully), nothing happens. Where recursion come from?
[systemd-devel] Antw: [EXT] Re: SOLVED: daemon-reload does not pick up changes to /etc/systemd/system during boot
>>> Alex Aminoff schrieb am 21.10.2022 um 18:11 in Nachricht : ... > 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)?
