Re: lvm2 deadlock

Dne 30. 05. 24 v 12:21 Jaco Kroon napsal(a):
> Hi,
> 
> Possible lvm2 command deadlock scenario:
> 
> crowsnest [12:15:47] /run/lvm # fuser //run/lock/lvm/*
> /run/lock/lvm/P_global: 17231
> /run/lock/lvm/V_lvm: 16087 17231
> 
> crowsnest [12:15:54] /run/lvm # ps axf | grep -E '16087|17231'
> 24437 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
> 16087 ?        S      0:00  |       |       \_ /sbin/lvcreate -kn -An -s -n 
> fsck_cerberus /dev/lvm/backup_cerberus
> 17231 ?        S      0:00  |           \_ /sbin/lvs --noheadings --nameprefixes
> 
> crowsnest [12:17:40] /run/lvm # dmsetup udevcookies
> Cookie       Semid      Value      Last semop time           Last change time
> 0xd4d2051    10         1          Thu May 30 02:34:05 2024  Thu May 30 
> 02:32:22 2024
> 
> This was almost 10 hours ago.
> 
> crowsnest [12:17:44] /run/lvm # dmsetup udevcomplete 0xd4d2051
> DM_COOKIE_COMPLETED=0xd4d2051
> crowsnest [12:18:43] /run/lvm # ps axf | grep -E '16087|17231'
> 27252 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
> crowsnest [12:18:45] /run/lvm #
> 
> Allows progress again.

Hi

I'm kind of missing here to see your 'deadlock' scenario from this description.

Lvm2 takes the VG lock - creates LV - waits for udev till it's finished with 
its job and confirms all the udev work with dmsetup udevcomplete.

If something 'kills'  your udev worker  (which may eventually happen on some 
'very very very' busy system - you may need to set up longer timeout for 
systemd to kill udev worker (I believe it's just 30seconds by default).

If it happens your cookies blocks your lvm2 command - you can 'unblock' them 
with  'dmsetup udevcomplete_all'  -  but that's a sign your system is already 
in very bad state.

It's also unclear which OS are you using - Debian, Fedora, ???
Version of your packages ?

Regards

Zdenek