Re: [EXT] Re: Q: handling generator-like dependency: target won't start on boot

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Thu, Sep 29, 2022 at 9:41 AM Ulrich Windl
<Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> >>> Andrei Borzenkov <arvidjaar@xxxxxxxxx> schrieb am 28.09.2022 um 20:34 in
> Nachricht <f287dedb-a58d-d4db-d25e-9bac20d585f7@xxxxxxxxx>:
> > On 28.09.2022 09:25, Ulrich Windl wrote:
> >> Hi!
> >>
> >> I'm trying to establish a mechanism that uses a generator-like mechanism as
> > described below. Unfortunately it starts when triggering the target manually,
> > but it never starts on system boot. I could need some advice how to make it
> > work.
> >>
> >> Basically I have a generator-like unit, say "g.servive", that creates other
> > instance-like services like i@.service.
> >> Finally I have a target, say "t.target", that wants (among others) those
> > instance-like services and is wanted by default.target.
> >>
> >> As said in the beginning: When booting the target does not start (and I
> > don't see any errors logged), but when I "systemctl start t.target",
> > everything starts up fine.
> >>
> >> More details:
> >>
> >> generator-like services:
> >> WantedBy default.target and t.target, and it "Wants=nss-user-lookup.target
> > time-sync.target  paths.target" (the Before= list is identical). In addition
> > it has "Before=default.target t.target".
> >> It starts a "oneshot" script that creates the instance-like services with
> > RemainAfterExit=true.
> >>
> >> instance-like services:
> >> PartOf=t.target, Requires generator-like.service (also After that service).
> > In addition it "Wants=nss-user-lookup.target time-sync.target paths.target"
> > (After= uses the same list). The service is Type=forking, and the unit is
> > WantedBy=t.target
> >>
> >> The script used in the generator-like service creates the unit files in
> > /run/systemd/system, and it runs "/usr/bin/systemctl daemon-reload" whenever
> > a unit file had been created or changed.
> >>
> >
> > daemon-reload does not re-evaluate initial "transaction" and your new
> > units are not used because they did not exist when this transaction was
> > computed.
>
> Hi!
>
> I don't quite understand what an "initial transaction" is,

The set of (start) jobs starting with default.targtet (or whatever
target was given to systemd as "initial target") and following
dependency chain (Wants and Requires). It is computed once when
systemd is started and it can only include units that are available
when systemd computes it. Anything added later (even if it has
dependency with units that are already part of the transaction) will
not be seen and used by systemd.

> but is sounds like a design deficit:

No, that is exactly how it was designed. systemd was created to start
the set of units during boot and stop these units during shutdown
(with monitoring and restarting running units). systemd never was
designed as a fully dynamic, event driven service manager.

Why do you think generators had been invented? Exactly because you
cannot modify the initial boot transaction and must provide units
*before* systemd starts computing this transaction if you want them to
be started on boot.

> The "real generators" (initially I wanted to use those) are too limited (i.e..: started too early in the boot process)

Now you know why.

> to be useful. I also noticed that daemon-reload seems to re-run the generators (like systemd-sysv-generator), so I wonder what use it will be if such generated units are being ignored.

They are ignored for the purpose of initial boot transaction which was
implied by dependency on default.target. They will be considered for
any transaction initiated after daemon-reload. I am not sure what
happens if you add more units as dependency of t.target after it has
already been activated and then issue "systemctl start t.target". Will
the start request be propagated to dependent units or not (I believe
it changed over time).

>
> At least what you write seems to explain what I see so far.
>
> Would it work to write yet another unit that starts t.target? If that would work, it clearly demonstrates the design problem in systemd.
>

I do not understand what you mean here. You need to give an example.