[systemd-devel] removing dm-crypt mapping hangs on shutdown
Colin Guthrie
gmane at colin.guthr.ie
Wed Jun 13 06:58:10 PDT 2012
'Twas brillig, and Dave Reisner at 13/06/12 01:50 did gyre and gimble:
> Hi,
>
> I'm having some problems with a few of my VMs which all share in common
> an encrypted root. They pivot into a shutdown ramfs and walk through the
> blockdevs in sysfs, breaking down and unmounting each device.
> Universally, these VMs all hang when calling 'cryptsetup remove', and
> only under systemd. The relevant bits of stack trace look something like
> this:
>
> ioctl(3, DM_DEV_REMOVE, 0xe1b8b0) = 0
> semget(0xd4d255f, 1, 0) = 229376
> semctl(229376, 0, GETVAL, 0xffffffffffffffff) = 2
> semop(229376, {{0, -1, IPC_NOWAIT}}, 1) = 0
> semop(229376, {{0, 0, 0}}, 1
I've seen similar symptoms in bug reports to your experience. Basically
hanging after detaching dm devices.
> I've found 2 solutions so far to avoiding this hang:
>
> 1) Not letting systemd get its paws on my block devices to umount them.
> Specifically, avoiding the dm_detach_all() call seems to alleviate this.
Yeah, it wouldn't be right to avoid it completely, but I agree that it
does need to skip things a bit more robustly.
> So this, to me, raises 2 questions:
>
> 1) Can systemd just leave block devices which it didn't assemble alone?
> I'd expect that if the initramfs assembled and mounted a device, it
> should be responsible for tearing it down. In theory, this could just be
> something as simple as just skipping over / and /usr.
I don't think a simply solution would work here as there are other cases
that may trigger the initramfs to enable certain devices (e.g. resume
from an encrypted swap partition for example).
I guess the initramfs should really write something in /run/initramfs
folder that indicates which devices it's "managing" such that systemd
can only deal with the remainder.
I'm not sure what the current status is, but I wonder what would happen
when systemd tries to unmount /usr just now... :s
> 2) What's the goal of calling mlockall() here? The original patch that
> added this (b1b2a107d15a) gives no indication of why it's wanted/needed.
No idea on this one.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the systemd-devel
mailing list