「ファイルを開く」ダイアログボックスがすべてのアプリケーションで表示されるまでに時間がかかります

「ファイルを開く」ダイアログボックスがすべてのアプリケーションで表示されるまでに時間がかかります

Ubuntu 14.04 の場合。

CtrlKeepassX を使用しているときに、 +ショートカットを使用してデータベースを開こうとしましたが、応答しないウィンドウが表示されてクラッシュしたようです。その後、Firefox、、 Eye of Gnome、および「ファイルを開く」ダイアログのあるほぼすべてのアプリケーションOで同じ動作が発生していることに気付きました。gedit

再起動後、もう一度試してみましたが、やはり同じことが起こります。しかし、結局、ダイアログ ボックスが表示されるまでに時間がかかり、表示される前にアプリケーションが応答しなくなる (クラッシュしたように見える) だけであることがわかりました。ただし、これは最初の 1 回のみ発生します。すでに実行中のアプリケーションでこの低速シーケンスを 1 回経験している場合、その後 Ctrl+を使用しOても速度は低下しませんが、アプリケーションを再起動すると、再び発生します (ダイアログ ボックスが最初に呼び出されたときのみ)。

テストに使用してeog、ターミナルで実行し、Ctrl+Oショートカットを使用しました。ダイアログ ボックスが表示される直前に次の出力が表示されます。

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

端末上で複数のアプリケーションをテストしましたが、結果は同じでした。また、アプリケーションをrootとして実行すると、ないただし、同じ効果があります。つまり、これらのアプリケーションを で使用すると、クラッシュしそうな遅い動作は発生しませんsudo。この出力から、起動時にパーティションとドライブがマウントされているため、おそらく uDisks と関係があると推測できます。また、ログインする前に外付けドライブが接続されている場合にのみこれが発生することをテストしたため、uDisks が関係しているように感じます。

この問題について私が他の場所で見つけた最も近いものはこのかなり謎めいたコメントSourceForge で、別のアプリケーション (私が所有していない、または使用していない) で同じことが起きていることについて、次のように投稿しています。

... gtk は、フォークされた子の孤立プロセスとして実行されることを好まないことが判明しました - 考えてみてください...

なぜこのようなことが起こるのでしょうか? 速度低下を解消するために何かできることはありますか?

答え1

geditWindows 10 で実行すると、同じ問題が発生します。

問題は、職場のネットワークと共有ドライブに VPN を使用して接続し、自宅で仕事を始めたときに発生しました。

問題は共有ドライブにあることが判明しました。ファイル ダイアログ プロセスは、ファイル ダイアログ ウィンドウを表示する前に共有ドライブをスキャンします。

共有ドライブには VPN 経由でアクセスするため、スキャンには非常に長い時間 (約 10 秒) かかります。

これについてはバグレポートがあります:参考:

答え2

何が原因なのか正確にはわかりません (Google で簡単に検索してみましたが、正直なところ、いくつかの理由のうちの 1 つである可能性があります)

しかし、私が見つけた最も一般的な解決策は、

sudo apt-get remove tracker --purge

トラッカー パッケージは不要で、多くの人が同じ問題を経験しています。これは、私が検索したすべての ( 3 ) フォーラムで機能しているようです :D あなたにも役立つことを願っています。

関連情報