Thunar hogging processor after problem mounting external drive

[markling]

I'll come back and fill in the details later.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: thunar 1.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-30.44-generic 3.8.13.6
Uname: Linux 3.8.0-30-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
Date: Wed Sep 11 13:27:30 2013
InstallationDate: Installed on 2012-11-28 (286 days ago)
InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1)
MarkForUpload: True
SourcePackage: thunar
UpgradeStatus: Upgraded to raring on 2013-05-14 (119 days ago)

[markling (markling)]

This occurs in different scenarios. Here's one:

Thunar devices list shows attached but unmounted external drive B. The drive is encrypted. In normal practice the following works as expected: mouse click drive B in Thunar devices list; Thunar gives popus asking for encryption password; password entered; Thunar accepts; drive mounts and opens in Thunar browser view.

However, >cancel< the password form before entering the password and the following happens:

- drive B in Thunar drive list shows a progress dial, that turns perpetually
- Thunar process consumes about 15 per cent processing power perpetually

Thunar doesn't want to let go.

Click it again, you can enter the password and it opens okay. But it essentially gives you no choice option but to click again and enter the password. If you don't then Thunar will just sit there tapping its foot, hogging your processor.

(Now as an aside here, there is an inconsistency that is a related but perhaps separate bug that is nevertheless worth mentioning. That is that if a drive is connected but not mounted, Thunar shows it so as a greyed-out entry in its drives list. But if, after you have mounted the drive, you use Thunar to dismount it (using, e.g. the Thunar >eject< buttton), the drive disappears from the list completely, meaning you have to intervene physically if you want to mount it again).

Here's another scenario, recounted slightly flakily from notes, but this is a good enough account to give some help in diagnosing the problem:

This error occured in a similar scenario the other day - another external USB disk that had been auto-dismounted on the count of midnight, also encyrpted. So the Thunar progress wheel is turning perpetually, using about 50 per cent processor time. I dismounted it from Thunar, but it stayed there in the devices list. I clicked on drive in Thunar devices list again. It disappeared from the list, and Thunar said: "device not found". But the drive was still mounted because quodlibet music player was using it. I closed all apps using the device and tried to dismount it from the command line, but system said I couldn't because the drive was busy. Another backup icon appeared in the devices list when I wasn't looking. I ejected it successfully this time and that was that.

[markling (markling)]

Here's another example.

External disk, encrypted, listed in Thunar devices. I click on it. Thunar brings pops up a password form. I enter the password incorrectly. The form disappears. I tried a few times. (Damned passwords). But then it seems Thunar hasn't let go of it. Thunar's 'busy' wheel is still turning beside drive in its devices list. The Thunar process is using 22% to 24% CPU.

If I now click on the problem device I get this message: "Failed to mount... operation already pending"

Ah.

It's because I've got more than one instance of Thunar open on different workspaces. The Thunar password form uses 24% CPU while it's waiting. If I attempt to get the same disk in another window, Thunar gives an error. It would help if it linked to the other password process, perhaps summoning the form (not the other Thunar window as well).

This case does not explain all instances of this problem.

[markling (markling)]

Very shortly after I filed that last report yesterday, Thunar crashed and bailed. This has happened before when its exhibited problems with external disks. It generated a bug report of the crash, which I sent.

[markling (markling)]

Here it is again. External drive. Windows fomatted. Ubuntu-encrypted. Left on overnight. Beyond midnight it gets auto-dismounted. Active applications (in this case Quod Libet) think it's still there till they try and access. They find it is not.

When you right-click / mount in Thunar, it gives the password form and takes the password but then gives an error saying device already exists.

Left-Click on device in Thunar device lists and same - password form, then error:

"Failed to mount... error unlocking... exited with non-zero exit status 5: device... already exists".

You have to eject and then physically remove and replace the device in order for it to work.

[markling (markling)]

Thunar just crashed out. Reconnected auto-dismounted disk. Got on with work. A different workspace, a different Thunar window: navigate into folder, navigate <up arrow> out again. Thunar hangs and bails out. Restart OK for now.

[markling (markling)]

Here's a more specific account of this problem:

External, USB, encrypted, windows disk.

Click on disk in Thunar device list. Thunar throws a password window up.
<Cancel> the action. Thunar closes the Window but retains the process. Thunar keeps the device busy in the Device list: its rotating icon still rotates, like it's waiting for something to happen. The Thunar process meanwhile takes about 11 per cent of CPU per Thunar window. i.e. with four windows open, Thunar will take 43 per cent of cpu resources.

The xfce4-panel 'places' drop-down does not exhibit the same problems while this is happening with Thunar.

So from here, if you click on the icon again, the same thing happens: Thunar throws the password window up, but it you don't put the password in it keeps hogging. Right-clicking gives you the options only to open or mount.

Opening the window again at this point does not recreate the problem (unless you click on the disk and cancel the password action again).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.