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.