Bug 107641
Summary: | Busy luks disk not closable forever if medium is removed | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Andrey Utkin (andrey.od.utkin) |
Component: | LVM2/DM | Assignee: | Alasdair G Kergon (agk) |
Status: | CLOSED DOCUMENTED | ||
Severity: | low | CC: | agk, gmazyland, snitzer, szg00000 |
Priority: | P5 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.3.0 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Andrey Utkin
2015-11-10 02:28:50 UTC
Well, firstly you need to try to work out what is still holding the device and why it cannot be removed and whether there is a controlled way to release it or whether it could be considered a bug. Secondly, see if there is a workaround that at least moves it out of the way so the name can be reused. At the dm layer, there are tricks like 'dmsetup rename' and 'dmsetup remove' which can also take --force and --deferred. If a running gpg-agent is the issue, do you need a mechanism for the udev rule to signal to that process that it must release the device first? - Try having the udev rule first kill the gpg-agent process. That could be generalised to kill all processes using the device being rules. Tools like 'lsof' show you what is using it. Thanks for quick reply. > If a running gpg-agent is the issue, do you need a mechanism for the udev > rule to signal to that process that it must release the device first? There would be a race condition anyway I believe. Maybe not in this, but in another application. I believe I can workaround my personal issue by symlinking that unix socket to outside of my encrypted stick. > Well, firstly you need to try to work out what is still holding the device > and why it cannot be removed I think I'll increase kernel log verbosity level and see what it gives. Otherwise, I have no idea how to debug that. Yes, or perhaps something like --no-use-standard-socket By enabling this option gpg-agent will listen on the socket named ‘S.gpg-agent’, located in the home directory, and not cre- ate a random socket below a temporary directory. Tools connect- ing to gpg-agent should first try to connect to the socket given in environment variable GPG_AGENT_INFO and then fall back to this socket. This option may not be used if the home directory is mounted as a remote file system. Note, that --use-standard- socket is the default on Windows systems. or probably the opposite --use-standard-socket I have GnuPG 2.1.9 and these options have no effect anymore. And there's no way to set socket location. --use-standard-socket --no-use-standard-socket --use-standard-socket-p Since GnuPG 2.1 the standard socket is always used. These options have no more effect. The command gpg-agent --use- standard-socket-p will thus always return success. Ok, killing gpg-agent works for me, but still - this smells like a bug of device mapper. The kernel quite correctly won't let you remove a filesystem or device in a safe and controlled way while it is still in use - it does look like your problem can be resolved entirely in userspace. If you can't find a way to control where the file is being placed, try the symlink idea, or speak to the gpg-agent developers. So you consider it perfectly correct to be unable to reuse /dev/mapper name after that, and if one wants to reuse it, he needs to resort to rebooting physical machine, because even "dmsetup remove" and "dmsetup rename" don't work? # dmsetup remove sensitive device-mapper: remove ioctl on sensitive failed: Device or resource busy Command failed [ERR] 15:01root@acer ~ # dmsetup remove --force sensitive device-mapper: resume ioctl on sensitive failed: Invalid argument device-mapper: remove ioctl on sensitive failed: Device or resource busy Command failed [ERR] 15:02root@acer ~ # dmsetup remove --force sensitive device-mapper: resume ioctl on sensitive failed: Invalid argument device-mapper: remove ioctl on sensitive failed: Device or resource busy Command failed [ERR] 15:02root@acer ~ # dmsetup remove --force --deferred sensitive device-mapper: resume ioctl on sensitive failed: Invalid argument [OK] 15:02root@acer ~ # ls /dev/mapper/ control sensitive [OK] 15:02root@acer ~ # dmsetup remove --force --deferred sensitive device-mapper: resume ioctl on sensitive failed: Invalid argument Renaming: # dmsetup rename sensitive sensitive_garbage device-mapper: rename ioctl on sensitive failed: No such device or address Command failed Are there still any users of the device? What does 'open count' of 'dmsetup info' output say? If so, you need to eliminate them first - kill the process, unmount the filesystem etc. The deferred remove OR the rename (but not both!) might have worked, but you need to look at the state with 'dmsetup info' after each command to find out. ('dmsetup info -c' gives a handy summary. Also 'dmsetup table' can show if a forced remove was attempted.) Sorry for the delay, will check in nearest days. The ideat that there may be some processes still having open files is reasonable, will check that. Maybe it is really the reason why closing doesn't work. |