[systemd-devel] reboot delay due to lack of VG deactivation before cryptsetup close
Andrei Borzenkov
arvidjaar at gmail.com
Mon Apr 2 17:02:56 UTC 2018
02.04.2018 04:05, Chris Murphy пишет:
> Summary: I have an LUKS encrypted partition, which is in turn made
> into a PV. So all the LVs made in this volume group are encrypted,
> including vg/swap which is found in fstab. The /etc/crypttab opens
> this LUKS device using a keyfile during boot.
>
> At reboot, there is a hang for cryptsetup, and the only device being
> used is vg/swap. It seems to me systemd should deactivate swap, and
> then it can deactivate the VG, and then it can stop cryptsetup. I
> *think* what's happening is it's not deactivating the VG, therefore
> the LVs are all still active even though they aren't in use, and
> therefore cryptsetup close is failing.
>
...
>
> If I'm right, this has nothing to do with swap being on this VG. Even
> without swap on it, the VG will still have active LV's, which will
> prevent cryptsetup close from completing. The VG has to be deactivated
> first.
>
>
You are most likely right, but I's say that is something LVM folks
should implement. So I would say this mail lacks at least one more
address in To or Cc :)
Of course there is generic problem of ordering services that are
responsible for configuring devices. Such service cannot be ordered
After device because otherwise device would never appear in the first
place. systemd refuses to order services Before device (it fails with
error message). So we can only add Requires or BindsTo and hope for the
best. But it also means that e.g. cryptsetup is not ordered against
services that need encrypted device. So during stop they will run
concurrently.
This is partially mitigated by the ordering of cryptsetup very early
during boot and hence very late during shutdown, so most services are
already stopped at this point. But if you are going to support arbitrary
deep stack of nested virtual devices this will become a real problem.
systemd needs clean framework to properly order service responsible for
setting up and tearing down device against all other units needing this
device.
More information about the systemd-devel
mailing list