Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] cryptsetup cannot close device which is unmounted
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
gabrielg
Tux's lil' helper
Tux's lil' helper


Joined: 16 Nov 2012
Posts: 98

PostPosted: Fri Jul 10, 2020 1:37 pm    Post subject: [SOLVED] cryptsetup cannot close device which is unmounted Reply with quote

This will be a long shot, but perhaps somebody can educate me with a more elegant solution or workaround.

Basically, I do this quite often on a running system:
Code:
losetup /dev/loop0 crypt_file
cryptsetup luksOpen /dev/loop0 crypt_dev
mount crypt_dev
# do some work
umount crypt_dev
cryptsetup luksClose crypt_dev
losetup -d /dev/loop0

The above works every time, unless the system is under load (e.g., compiling a large package). This is what I get when trying to run luksClose in such conditions:
Code:
device-mapper: remove ioctl on crypt_dev  failed: Device or resource busy


What is interesting is that there _should_ be nothing using that device - lsof doesn't report anything at least. My current workaround is to wait until whatever is happening finishes, and then issue the last commands myself. Needless to say, this is not script friendly :)

Ideally, I want umount to lock until it's really done and ready for me to run the luksClose command; or at least to find a way to check that the LUKS device has no pending operations so that I can go ahead and close it.

Any ideas and/or comments will be more than welcome! I certainly had a look at the kernel documentation for device-mapper and couldn't find anything that seemed relevant. I did try to sync before umount, but that didn't help either.

Some relevant system information (but ask for more if I missed something):
* kernel 5.4.48 (but this has been happening for a very long time)
* cryptsetup 2.3.2 (same as above)

Thanks!


Last edited by gabrielg on Sun Jul 12, 2020 12:03 pm; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15604

PostPosted: Sat Jul 11, 2020 12:07 am    Post subject: Reply with quote

I suspect that this is not about load, but about what else is being done. Please try this experiment:
  • Open/mount your encrypted device.
  • In a separate root shell, run /usr/bin/unshare -m /bin/sleep 60.
  • While the sleep is running, unmount and close the device. I expect it to fail, just as you described.
  • When the sleep finishes, retry the close. I expect it to succeed.
If you need more than 60 seconds to run this experiment, make the sleep run longer. If all this works as I expect, then it suggests that your problem is not related to load, but to mount namespaces. When a mount namespace is forked from its parent, it inherits all existing mounts. When you ran umount, you only unmounted in the namespace where you ran that. The device remains mounted in any other mount namespaces where it was mounted, preventing you from closing the device. When the other mount namespaces exit, such as because all the processes in them have terminated[1], then your filesystem is finally fully unmounted, and the device can be closed.

If I am right, then you have a few options:
  • Create a private mount namespace before you mount the filesystem, and do not start anything in that private namespace that would create more namespaces. In particular, do not run emerge from that namespace. Instead, run it from the main namespace. This approach is fine if you just need one root shell to use the protected filesystem. It gets a bit cumbersome if you want several concurrent root shells to use it, and more cumbersome still if you want non-root processes to use it.
  • Mount the protected filesystem below a mountpoint that is itself marked for sharing, so that your unmount propagates into the other namespaces. See man mount_namespaces for details.
  • Add your own wrapper around emerge and anything else that is creating these new namespaces, and in that wrapper, set up a new namespace yourself, unmount the filesystem in that private namespace, then exec the wrapped program. When it creates a new namespace, it will inherit from the private one that you just unmounted in, so it will not pin the protected filesystem.
  • When you are ready to unmount the filesystem, find all the namespaces where it is mounted and unmount it in each of them. This would be fine for a one-off, but if you want to do it routinely, you probably want a script to handle this. If I were dealing with this issue, I would prefer one of the other options. (I don't deal with this issue anymore, because I had exactly this problem, and elected to solve it by having the protected filesystem mounted in a private namespace.)
[1] With the right setup, a mount namespace can exist while there are no processes using it. This is probably not relevant to your problem.
Back to top
View user's profile Send private message
gabrielg
Tux's lil' helper
Tux's lil' helper


Joined: 16 Nov 2012
Posts: 98

PostPosted: Sun Jul 12, 2020 9:58 am    Post subject: [SOLVED] cryptsetup cannot close device which is unmounted Reply with quote

Thanks, Hu, this was really useful and indeed I can reproduce the issue in the way you suggest, so I'm marking this thread as solved (even though I still have to fix my script issue, but that's another story).

Frankly, I never thought namespaces will ever affect "normal" operations such as the ones I was making, but now I know something new and have an excuse to familiarise myself with namespaces.

Thanks again!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum