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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
