systemd version the issue has been seen with

main

Used distribution

No response

Linux kernel version used

No response

CPU architectures issue was seen on

None

Component

No response

Expected behaviour you didn't see

No response

Unexpected behaviour you saw

In repart we allow setting up encrypted partitions. To set up an encrypted partition, we use libcryptsetup to activate the luks device and then open a file descriptor to it which we then BSD lock to avoid udev from messing with it while we're operating on it. However, when we want to clean up the device, we have to close the file descriptor before deactivating the device with libcryptsetup, which leaves open a window for udev to start messing with the luks device, causing the deactivation to fail with EBUSY.

Ideally we would keep the lock intact while we deactivate the luks device so that there is no window where we don't have the lock while deactivating the lock but I'm not sure if libcryptsetup supports such a scenario.

@oniko Any suggestions on how we can handle this race condition?

Steps to reproduce the problem

No response

Additional program output to the terminal or log subsystem illustrating the issue

No response