ensure blk_availability only deactivates devices after local-fs.target #18
Comments
Currently on shutdown blk_availability will start almost as early as possible and invoke blkdeactivate. This can make devices and the filesystems on them unavailable that will still be needed by other parts of the shutdown. Usually such services needing the local filesystem will have declared After=local-fs.target And expect to be shut down before things are unmounted. But blkdeactivate might unmount things before all of that. To guarantee no devices / filesystems going away too early let us declare for blk_availability: Before=local-fs.target On shutdown that ensures that blkdeactivate will only be ordered after local-fs.target which seems what users would expect. Fixes: lvmteam#18 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
|
Yes, this is an issue, it's already reported here as well: https://bugzilla.redhat.com/show_bug.cgi?id=1701234. The problem here is, that some other services which blk-availability orders itself to can contain After=local-fs.target, including all the recursive dependencies (e.g. some service in the dependency chain may require the local filesystems to be mounted to read the configuration for the service to start). Hence we'd get into an ordering loop then and one of the services would be shot down by systemd. So the fix here is more broader and we probably need to come with new (systemd) targets and maybe split the blk-availability.service in two so we can still properly order it properly with respect to other services. |
|
Interesting, thanks for the details - subscribing there to stay up to date what happens. |
Hi,
in a bug to Ubuntu I got a case reported where the lack of ordering on shutdown causes issues.
I have seen #17 but that only guarantees to have blk_availability complete before reaching shutdown, this is different.
On shutdown due to a lack of
Beforestatements or any other service depending on it viaAftermeans that blk_availability will start very early in the shutdown ordering. That can lead to cases (see reported bug) where devices and associated filesystems are gone while still being needed.If there is any other safeguard that should avoid this, but failing in this case let me know.
Just looking at systemd for shutdown ordering I'd have expected that we'd want to start
blkdeactivateonly afterlocal-fs.targetis reached.That would mean any services needing local disks/FS are done and that implies we can safely
blkdeactivatenow.The text was updated successfully, but these errors were encountered: