[securedrop-export] device mapper sometimes busy when exporting

[sssoleileraaa]

Description

We've removed the "Export Successful" message from securedrop-export and are getting ready for the client to wait until either no status (meaning success) or a status containing an error message is returned. #666 surfaces a bug where sometimes the client receives an error message device-mapper: remove ioctl on luks-<unique id> failed: Device of resource busy, however the file transfer is successful.

More details

The bullets below indicate that the device is properly being mounted/unmounted locked/unlocked:

• Looking at securedrop-export logs, I see all three of these logs appear when this error is returned to the client: https://github.com/freedomofpress/securedrop-export/blob/9526fe4558a4fa2872cd4b9249ce9865030eeb99/securedrop_export/disk/actions.py#L180-L192

• I also see the 2 "Device removed" Qubes popups when we mount the device after unlocking it and the 2 "Device available" popups when we unmount and lock the device

• Exporting a file again from the client, after seeing this error, will sometimes succeed without returning the error message device-mapper: remove ioctl on luks-<unique id> failed: Device of resource busy

• Regardless of the error, the file seems to successfully transfer each time

[sssoleileraaa]

Since this is not reproducible we should remove the release blocker tag or just close this issue.

[redshiftzero]

Since we still haven't seen this in QA, I'm going to close this for now, let's reopen if we see again

[rocodes]

Great(?) news, I have just repro'd this when I was testing scenarios for #1734.

Error msg 1 (can repro almost 100% of the time):

STR: insert USB, unlock via Nautilus in sd-devices (I have repro'd with both the "Forget password immediately" option and the "remember for x time" options), navigate to a folder inside the export device (eg a previous export archive) to keep the device busy

Error msg 2 (can repro 100% of the time) if you keep the device busy by e.g. cd ing into the /media/user/device-id-xxxxx directory in an sd-devices terminal

• The export occurs successfully, but an error message is shown (see attached screenshot)
• Logs
• The reason the error shows up here is because the cleanup part of our 'copy submission` method also locks and unmounts the drive, so the user sees an error (with unmounting the drive) even though the export itself succeeded.

[rocodes]

I think a user would have to go out of their way to encounter this issue (i.e. by interacting directly with sd-devices to unlock the device instead of using the export workflow), and I think the fixes are pretty straightforward (such as clearer messaging in the export flow that indicates that the export itself was successful, but there's a problem unmounting the drive, and/or better error-handling as we unmount the drive if we detect that it's in use by another process on sd-devices).

[gonzalo-bulnes]

I see you've commented on this issue before @rocodes. It seems to me that this scenario would be handled as Status.ERROR_EXPORT_CLEANUP, wouldn't it? (#105)

[rocodes]

Fixed in #1779, closing