On 2018-12-19 12:13, Guilhem Moulin wrote: > On Wed, 19 Dec 2018 at 04:59:47 -0800, r...@riseup.net wrote: >> When I manually applied the patch from #5, my shutdown sequence worked >> just fine (without hanging). > > Dunno what Devuan ships, but that patch simply doesn't apply to the > debian/cryptdisks.functions from cryptsetup 2:1.7.3-4:
I apllied it manually. > https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/cryptdisks.functions/#L764 > > What does cryptdisks.functions:do_stop() looks like after your > modifications? FWIW, I see two issues with the proposed patch from > #792552's 5th message: > > 1. The inner loop is run in a sub-shell, so changing the value of the > ‘ITERATE’ variable there has no effect in the outer loop. > > 2. Both our /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early > scripts are run with `set -e`, so if handle_crypttab_line_stop()'s > return code is not 0 then the script errors out immediately. > > I believe that's why your system doesn't hang anymore. The device > that's holding the root file system is busy (regardless of LVM, / and > /usr are still mounted) hence can't be closed, making the init script > error out instead of retrying and/or closing other devices defined in > /etc/crypttab. It shortens the shutdown sequence by 30s or so, but it > also breaks the intended semantics, namely closing all dm-crypt devices > that can be closed. > >>> /etc/init.d/lvm2 no longer deactivates LVs on shutdown since lvm2 >>> ≥2.02.84-3. But I don't see which doing so should be the job of >>> /etc/init.d/cryptsetup instead. >> >> I understand your reasoning. So this should be changed from a cryptsetup >> bug to a lvm one? > > Perhaps /etc/init.d/lvm2 should deactivate LVs that are not required > further down the shutdown sequence (such as those holding / or /usr), > but it won't be able to deactivate everything either. The dm type > (dm-crypt, linear, etc.) is irrelevant, if the mapped device is holding > / or /usr then it should be preserved. > >>> Regardless, we won't be able to lock devices holding / or /usr. AFAICT >>> that's where `/etc/init.d/cryptdisks stop` is choking with the repeated >>> “… is busy” messages. For these devices the script might as well return >>> failure immediately and not try again. >> >> That sounds like a rather _brute_ solution but it might just as well >> work. > > How so? With the patch from #792552's 5th message *all* busy dm-crypt > devices (more generally *all* devices that can't be closed on first > try), are left open as well. > > /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early are *not* run > last in the shutdown sequence, so at this stage the root file system > (and /usr) still needs to be present. Hence there no way we can > reliably close underlying dm-crypt and/or linear (LVM2) devices. We can > close devices holding other file systems though, since they should be > unmounted at that point. I see. What would you suggest as a proper solution to this situation? Rodrigo
