[systemd-devel] removing dm-crypt mapping hangs on shutdown
Dave Reisner
d at falconindy.com
Wed Jun 13 06:09:55 PDT 2012
On Tue, Jun 12, 2012 at 08:50:46PM -0400, Dave Reisner wrote:
> 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 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.
> 2) Removing the mlockall() call in src/core/shutdown.c on line 351
> (according to git master as of this posting).
Hmm, so as mysteriously as I thought this fixed my problem, it doesn't.
It does significantly lower the occurrence of the hangs, though. It's
more like a 1:10 ratio rather than a 2:3.
Regardless, I'd be more interested in finding a solution that involves
systemd not touching devices that it didn't assemble/mount.
>
> 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.
> 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.
>
> Cheers,
> Dave
More information about the systemd-devel
mailing list