Arch Linux

See related dm-devel mailing list thread at:

dm-devel@redhat.com/msg02361.html"> https://www.mail-archive.com/dm-devel@redhat.com/msg02361.html


Description:

After systemd 231 (commit d4506129) changed the timeout on sending a SIGKILL after a SIGTERM from 10 seconds to 90 seconds, the 90 second delay in reboots rather than 10 seconds I had previously sent me digging. Turns out when using thin volumes, lvm-lvmetad and dm-event services are ignoring systemd's SIGTERM, and eventually being SIGKILL'ed by systemd. This has been happing for quite some time, months at least.

I had modified my systemd services to only give these services 3 seconds, but I got a response from a RedHat developer saying SIGKILL'ing dmeventd during a recovery operation and also lvmetad can "leave your system in a dizzy state (suspended devices) essentially useless".

If I'm interpreting this correctly, I think there's a possibility of data loss IF you happen to manually stop these services, shutdown, or reboot, while one of the services is modifying something such as auto-extending. Seems like a remote situation to me, but wanted to pass it along.

Short of that, it's probably just irritating Arch users using thin volumes on why reboots are so slow all of a sudden.

He says dm-event ignores SIGTERM/SIGINT when a device is being monitored.

But after running:
==========
for lvDeviceName in $( lvs --noheadings -o dmpath ); do
lvchange --monitor n ${lvDeviceName
done
for volumeGroup in $( vgs --noheadings -o vg_name); do
vgchange --monitor n ${volumeGroup}
done
==========

Then running systemd stop dm-event, still gives a 90 second timeout. So something else is going on.

At this point, I'm wondering if I can just not use lvm2-lvmetad and dm-event. My understanding is lvm2-lvmetad just caches the LVM information so the disks don't have to be scanned on commands line lvs. dm-event is a bit more vague, that it's for library plugins... But I think it's mainly for stuff like auto-extend which could be done manually, granted automatically could prevent a volume unexpectedly becoming unwritable.


Additional info:
linux 4.7.0-1, lvm2 2.02.164-1

The RedHat developer also said: "Fedora should be doing it properly on reboot - switching to ramdisk and continuing with shutdown sequence from there. Unsure how other OS-es solves this."

I admit I don't know much about Arch's shutdown procedure, much more familiar with its booting procedure.

I might see if I can reproduce this using Arch in a VM, and if so, see if I can reproduce this using Fedora in a VM.


Steps to reproduce:

Here are the minimal steps I used to cause the problem, using one disk and EXT4.

If during the install I combine the 2 lvcreate commands into a single one without using thin pools, then lvmetad terminates pretty much immediately with SIGTERM.

===================

/dev/sda1 3.5G Linux filesystem
/dev/sda2 4.5TB Linux LVM

{ Setup LVM and filesystems }
# mkfs.ext4 -L boot /dev/sda1
# pvcreate /dev/sda2
# vgcreate disk1 /dev/sda2
{ Merging these 2 lvcreates, removing the thin volume usage makes lvm2-lvmetad properly terminate on SIGTERM }
# lvcreate --size 500G --thinpool disk1thin disk1
# lvcreate --virtualsize 100G --name root disk1/disk1thin
# mkfs.ext4 -L /mnt /dev/disk1/main
# mount /dev/disk1/main /mnt
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

{ Install Arch Linux }
# vi /etc/pacman.d/mirrorlist
# pacstrap -i /mnt base syslinux gptfdisk lvm2
# arch-chroot /mnt
# vi /etc/locale.gen
# locale-gen
# locale > /etc/locale.conf
# vi /etc/nsswitch.conf
# systemctl enable systemd-resolved systemd-networkd
# ln -s /usr/share/zoneinfo/America/Detroit /etc/localtime
# hwclock --utc --systohc
# passwd
{ Add lvm2 between block and filesystems }
# vi /etc/mkinitcpio.conf
# mkinitcpio -p linux
# echo hostname > /etc/hostname
# vi /etc/systemd/network/enp31s0.network
# syslinux-install_update -i -a -m
# vi /boot/syslinux/syslinux.cfg

{ After Reboot }
# systemctl stop dm-event || systemctl poweroff || systemctl reboot