[systemd-devel] reboot delay due to lack of VG deactivation before cryptsetup close

[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.


journal log
https://drive.google.com/open?id=1PAX7RwKYi5WzwpRfPxQrS-IzhCchZy88


[chris at f27s ~]$ uname -r
4.15.14-300.fc27.x86_64
[chris at f27s ~]$ rpm -q systemd
systemd-234-10.git5f8984e.fc27.x86_64


[  547.107624] f27s.localdomain systemd[1]: Deactivated swap /dev/vg/swap.

Looks like swap really is deactivated.

[  551.832626] f27s.localdomain systemd-cryptsetup[1473]: Failed to
deactivate: Device or resource busy

Before this message, I see no evidence the VG is deactivated first and
thus probably why cryptsetup close fails. So it hangs for a 1m30s.

[  635.123287] f27s.localdomain systemd[1]: lvm2-lvmetad.service: Main
process exited, code=killed, status=9/KILL

and

[  637.132128] f27s.localdomain systemd[1]: dm-event.service: Main
process exited, code=killed, status=9/KILL


And then reboot happens.

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.


-- 
Chris Murphy