16

On Ubuntu 14.04.

While using KeepassX, I tried to open a database with the Ctrl+O shortcut, but it appeared to crash with a non-responsive window. I then noticed the same behavior with Firefox, gedit, Eye of Gnome and nearly any application I have with an "Open File" dialog.

Upon restart, I tried it again and it still happens. Eventually, though, I found out that the dialog box just took a long time to appear and it just renders the application non-responsive before it does (making it look like it crashed). It only happens the first time, though. Subsequent usage of Ctrl+O won't slow down anymore on an already running application that has already gone through that slow sequence once, but it does happen again (still only the first time the dialog box is called) once the application is restarted.

Using eog to test, when I ran it on a terminal and used the Ctrl+O shortcut. The following output appears right before the dialog box does:

Error creating proxy: Error calling StartServiceByName for org.gtk.Private.UDisks2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)

I tested multiple applications on a terminal with the same effect. I also noticed that running applications as root does not have the same effect, though. That is to say that the slow looks-like-it's-crashing behaviour doesn't happen when using those applications with sudo. From that output, I can infer that it probably has something to do with uDisks since I have partitions and drives mounted at startup. I also feel like uDisks has something to do with it because I've tested that this only happens if my external drives are plugged in before I'm logged in.

Closest thing I can find about the problem elsewhere is this rather cryptic comment on SourceForge about it happening to another application (that I don't have or use) saying:

... turns out that gtk doesn't like to run as a forked child orphan process - go figger...

What can possibly be the reason as to why this happens? Is there anything I can do to get rid of the slowness?

maki57
  • 407
  • 1
  • 4
  • 11
  • me too, except I'm on Debian sid, but all the rest is identical to your description. Have you managed to resolve the problem? – Lucio Crusca May 20 '18 at 06:43
  • Technically, it's been "resolved" years ago (i.e. I don't have the problem anymore), but I didn't do anything that I believe would've fixed it. I dealt with the slowness for some time and then it just stopped being slow. I distinctly remember not updating anything at the time or installing anything new, though. Sean Davey's solution below might help you out. – maki57 May 21 '18 at 03:40
  • Thanks @maki57 I had already tried that solution but it didn't help. – Lucio Crusca May 22 '18 at 05:39
  • Here is how I eventually solved the problem: https://lists.debian.org/debian-user/2018/07/msg00043.html – Lucio Crusca Jul 10 '18 at 16:27

2 Answers2

1

I have the same problem when running gedit on Windows 10.

The problem started when I started working from home using a VPN to connect to the network and shared drives at work.

The problem turned out to be the shared drives: The file dialog process scans the shared drives before showing the file dialog window.

Because I access the shared drives over a VPN, scanning them takes a very long time; around 10 seconds.

There is a bug report for this: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1820866

NZD
  • 2,600
  • 16
  • 22
0

not sure exactly whats causing this, ( did a quick google search for you, and could be one of a few reasons tbh )

but by far the most common solution I found was to try 

sudo apt-get remove tracker --purge

the tracker package is not necessary and is causing a lot of people to experience the same problem. This seemed to work for ALL ( 3 ) the forums I searched :D hopefully it can help you also.

Sean Davey
  • 494
  • 4
  • 11