On Thu 17 Feb 2022 11:58, Martin Wilck wrote:

The main reason is that SYSTEMD_READY=0 is set too late, in 99-systemd-
rules, and only on "add" events:
https://github.com/systemd/systemd/blob/bfae960e53f6986f1c4d234ea82681d0acad57df/rules.d/99-systemd.rules.in#L18

I guess the device-mapper rules themselves could be setting
SYSTEMD_READY="0". @Peter Rajnoha, do you want to comment on that? My
concern wrt such a change would be possible side effects. Setting
SYSTEMD_READY=0 on "change" events could actually be wrong, see below.

We need to be very careful with SYSTEMD_READY as switching that from 1
to 0 would cause the systemd device unit to stop. And services can be
bound to device existence (that is, systemd device unit). If we just
temporarily suspend a DM device and not completely removing it, then
we might get out-of-sync easily when it comes to notion of device
presence in various parts of the system.

One thing is device presence, the other are various sub-states that
a single SYSTEMD_READY is not covering, like the suspended state...

-- 
Peter