Conflation of propagation in dependencies creates race windows

[Jonathon Kowalski <bl0pbl33p@xxxxxxxxx>]

Hi list,

We recently had a bug report
https://github.com/systemd/systemd/issues/11456 where I see that
specifying two separate and perfectly fine propagation deps creates a
race window where a job gets pulled in, installs itself in the unit's
job slot, and claims the state change to itself (finishing hence),
inhibiting the trigger of a restart. While this might not make it
clear what exactly is wrong, a look at
https://github.com/systemd/systemd/issues/1154 which is similar in
nature convinces me that systemd currently conflates two many
properties in the same dependency. The second bug in particular would
not happen if there was a version of Requires= that disabled the
PartOf= stuff it currently has, i.e., pick and choose deps.

I guess that makes things more verbose, but it also creates
unavoidable scenarios like the two I pointed out above. Hence, I think
we should instead internally have very primitive propagation types,
expose them, and then map these higher level dependencies to them
keeping compatibility. Currently, there is no way to decouple
PartOf='s stop job propagation and only that, a need for that popped
up when exploring https://github.com/systemd/systemd/issues/11421. I
also currently have a PR that implements an InterruptedBy= dependency
that only forwards stop jobs when something goes down unexpectedly
without a job's involvement:
https://github.com/systemd/systemd/pull/11340.

Currently, some are either too coarse, or fundamentally too rigid,
that if one needs something in between, they're SOL.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel