Long delay when opening Nemo / file dialogs #2497

mikehaertl · 2020-08-30T10:31:29Z

 * Nemo version 4.6.5
 * Is issue with desktop or windowed nemo? both
 * Distribution - Mint 20
 * Graphics hardware *and* driver used
Graphics:  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics vendor: ASRock driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:0412 
           Display: x11 server: X.Org 1.20.8 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1200~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 4600 (HSW GT2) v: 4.5 Mesa 20.0.8 compat-v: 3.0 direct render: Yes 
 * 64 bit

Issue

Sometimes suddenly opening Nemo (and any other file dialog from other programs) is delayed by 25 seconds. It probably has to do with gvfsd-trash not responding, see below.

Steps to reproduce

There is no clear procedure to reproduce.

Expected behaviour

It should open immediately.

Other information

Upstream issue in Gnome: https://gitlab.gnome.org/GNOME/gvfs/-/issues/485 (and related: https://gitlab.gnome.org/GNOME/glib/-/issues/1941)
Forum discussion: https://forums.linuxmint.com/viewtopic.php?f=47&t=328966.

Opening the issue here as per suggestion of forum member smurphos.

Workaround

killall gvfsd-trash fixes the issue without a reboot.

The text was updated successfully, but these errors were encountered:

starsep · 2020-09-06T17:59:57Z

I confirm the bug, workaround works. Without it is takes more than 25 seconds, with it less than 2.

Rinkaa · 2020-10-07T16:09:03Z

I have a similar issue. Sometimes suddenly it takes more than 60 seconds to start a new nemo window (even when there is an existing dialog). killall gvfsd-trash does not fix the issue but killall gvfsd does in my case.

My-Random-Thoughts · 2020-10-15T07:46:08Z

I have a similar issue on version 4.4.2. I "fixed" it by reinstalling all the gvfs* packages (7 in my case). That was before I saw this open bug! :)

EDIT: Using Ubuntu 20.04 with Cinnamon

mikehaertl · 2020-12-11T14:20:32Z

The upstream issue in Gnome has been fixed now: https://gitlab.gnome.org/GNOME/gvfs/-/issues/485.

@icarter09 I assume that we just have to wait until the fix makes it into the Ubuntu gvfs-daemons package, right? Or is there anything we could do to speed this up?

icarter09 · 2020-12-12T04:05:19Z

@mikehaertl thanks for the heads up that it's been fixed upstream. I'll see about what can be done to get it implemented sooner.

edupsousa · 2021-05-21T01:05:01Z

Hi guys, thanks for your work on Nemo. There's a safe way to manually use gvfs packages from a new Ubuntu version?

Nemo sudenly became very slow, killall gvfsd-trash seems to solve until the next reboot. Debug shows a long time between those 2 lines:

** (nemo:73765): DEBUG: 21:33:53.869: open_window: ../src/nemo-main-application.c:327: Opening new window at uri file:///home/edupsousa
** (nemo:73765): DEBUG: 21:34:18.943: nemo_main_application_create_window: ../src/nemo-main-application.c:219: Creating a new navigation window

Mint 20.01
kernel 5.4.0-73
gvfs-daemons 1.44.1-1ubuntu1
nemo 4.8.6+ulyssa

RandomGHUser · 2021-06-23T15:55:47Z

Any progress on pushing this to mint via standard updates? It really is an annoying bug, and it happens frequently.

offset8 · 2021-08-02T12:35:28Z

I have a similar issue. Sometimes suddenly it takes more than 60 seconds to start a new nemo window (even when there is an existing dialog). killall gvfsd-trash does not fix the issue but killall gvfsd does in my case.

Same here ! Got this issue today, and killall gvfsd fixed it

mikehaertl · 2021-10-15T17:36:58Z

@icarter09 Are there there any news here? It seems like the situation got worse for me now. It freezes almost once a day now. Before it was only about once a month.

buck2202 · 2021-10-15T17:50:46Z

@mikehaertl I was getting it multiple times a day. But I've noticed that keeping a nemo window always open in the background prevents gvfsd-trash from respawning. Of course, I can't access my trash, but it least avoids the hangs...

When I do need to access the trash, I close all nemo windows, open a new one and wait for gvfsd-trash to respawn. Then it'll hang again within an hour or so, so, kill it again

edit: I take it back. gvfsd-trash is respawning even with my background nemo window..seems that other things can trigger it. I just had to kill gvfsd-trash multiple times in a minute.

buck2202 · 2021-10-16T04:46:51Z

the ubuntu bug is here: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100?comments=all

buck2202 · 2021-10-16T08:13:59Z

Alright, last comment in my flood of them..

For whatever reason, it definitely feels like the frequency of the lockups has gotten much worse recently. After a really frustrating run of having to kill gvfsd-trash multiple times in an hour, I

downloaded the 1.44.1-1ubuntu1 tarballs from https://packages.ubuntu.com/focal/gvfs-daemons
manually created a patch based on this PR https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/96/diffs
rebuilt the deb packages with this patch listed last in debian/patches/series (which was a pain...gvfs has a huge number of dependencies), ~~added a note to control.in so that I could confirm in synaptic that I got my new build, and installed it over the repo version~~, setup a local deb repository, and installed the whole gvfs* mess of seven packages. synaptic kept trying to "fix" things for me when I tried using only gvfs-daemons
ran killall gvfsd to hopefully clear out everything, and let it respawn from the new version

and it does seem like the issue is resolved. It's actually amazing how much snappier everything feels. I'll comment again in a few days if I experience any issues.

This is the patch that fixed it (made from the gitlab link above), but I'm not sure how to go about submitting it, or how to get any attention on the (also stale) ubuntu bug report. Any Mint maintainers that could lend a hand?

--- a/daemon/trashlib/dirwatch.c	2020-03-27 08:29:59.000000000 -0400
+++ b/daemon/trashlib/dirwatch.c	2021-10-16 00:57:40.985738068 -0400
@@ -216,6 +216,7 @@
       watch->state = FALSE;
     }
 
+  g_file_monitor_cancel (watch->parent_monitor);
   g_object_unref (watch->parent_monitor);
   watch->parent_monitor = NULL;
 }
@@ -271,7 +272,10 @@
   if (watch != NULL)
     {
       if (watch->parent_monitor)
-        g_object_unref (watch->parent_monitor);
+        {
+          g_file_monitor_cancel (watch->parent_monitor);
+          g_object_unref (watch->parent_monitor);
+        }
 
       g_object_unref (watch->directory);
       g_object_unref (watch->topdir);

buck2202 · 2021-10-16T11:09:41Z

Ok, last last comment--I made a debdiff from my rebuild and posted it to the ubuntu tracker. Hopefully it helps get some attention

LinuxOnTheDesktop · 2021-12-30T08:00:10Z

It remains the case with Nemo 5.0.5 that trashing moderately many files causes (or at least can cause) the system to stall for quite a while and simultaneously for CPU use to rocket.

If the problem really is upstream, is it fixed? Or is the problem with Nemo (as this report, filed against gvfs) seems to give reason to believe)? The problem seems pretty serious to me: it is a sizeable flaw in basic functionality.

buck2202 · 2021-12-30T17:35:18Z

It is fixed in newer gvfs; or, at least, the issue reported here is. Your description sounds a bit different.

I haven't had the issue once in the 2+ months since I applied the gvfs patch above to my machine locally. I've submitted it to ubuntu, it's just waiting to be accepted

LinuxOnTheDesktop · 2021-12-30T18:08:53Z

@buck2202

Thank you for your most recent comment and for your prior documenting of the fix. That fix is rather involved for the user to apply. Do you have a link to your Ubuntu PR? (Thank you for making that PR, too.)

I will file my problem separately.

buck2202 · 2021-12-30T18:14:05Z

I posted my patch in the ubuntu bug from a few comments up: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100?comments=all

It's currently just waiting for a "sponsor" to circle back to it, after I made some documentation changes required of a patch to a stable release. I thought about creating a PPA with the fix to link here, but hoped the ubuntu process wouldn't drag on very much longer. If it goes much into the new year, I'll try to figure that out.

buck2202 · 2022-01-22T19:22:09Z

If there's anyone out there using Ubuntu+Nemo (not Mint), we could use your help over at launchpad. They need an ubuntu user for testing before they'll consider accepting my patch. https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100?comments=all

My-Random-Thoughts · 2022-01-22T20:09:44Z

If there's anyone out there using Ubuntu+Nemo (not Mint), we could use your help over at launchpad.

I am using Ubuntu+Nemo, however I have not experienced the issue for quite a while.

Ubuntu 21.10 
Cinnamon 4.8.6
Linux 5.13.0-25

buck2202 · 2022-01-22T20:44:52Z

Sorry, I should've been more specific...ubuntu 20.04 LTS. The issue shouldn't exist in >=21.04 as they have newer gvfs packages that already include this patch.

buck2202 · 2022-05-09T11:25:59Z

This took a while, but should be fixed in gvfs 1.44.1-1ubuntu1.1
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1927100

(make sure you either reboot, or nemo -q and killall gvfsd after updating)

LinuxOnTheDesktop · 2022-09-11T14:30:53Z

Just now I may have encountered the problem on Mint 21 with gvfs version 1.48.2.

( was opening my first Nemo window of the session (or at least the first one since suspend). I do have gvfs paths bookmaked. Yet, I don't think I clicked such a bookmark. The system stopped responding to most input; but ctrl-alt-shift-print-R-E-I seemed to restore control. I see nothing in the logs.)

Is anyone else encountering a resurrection of the bug that this issue page treats?

buck2202 · 2022-09-11T15:20:18Z

The (temporary) lock-up from this bug never extended beyond nemo/file chooser dialogs, the rest of the system stayed responsive. I haven't updated to 21, but I'd suggest that it doesn't sound like the same issue

LinuxOnTheDesktop · 2022-09-11T18:02:15Z

@buck2202: yes, my problem does seem different. If the problem reoccurs then I will try to get more data and if I can do so then I will open a new issue.

icarter09 added the BUG label Nov 11, 2020

LinuxOnTheDesktop mentioned this issue Dec 30, 2021

Stall, with high CPU usage, when deleting a large-ish number of files #2900

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Long delay when opening Nemo / file dialogs #2497

Long delay when opening Nemo / file dialogs #2497

mikehaertl commented Aug 30, 2020 •

edited

starsep commented Sep 6, 2020

Rinkaa commented Oct 7, 2020

My-Random-Thoughts commented Oct 15, 2020 •

edited

mikehaertl commented Dec 11, 2020

icarter09 commented Dec 12, 2020

edupsousa commented May 21, 2021

RandomGHUser commented Jun 23, 2021

offset8 commented Aug 2, 2021

mikehaertl commented Oct 15, 2021

buck2202 commented Oct 15, 2021 •

edited

buck2202 commented Oct 16, 2021

buck2202 commented Oct 16, 2021 •

edited

buck2202 commented Oct 16, 2021

LinuxOnTheDesktop commented Dec 30, 2021

buck2202 commented Dec 30, 2021 •

edited

LinuxOnTheDesktop commented Dec 30, 2021 •

edited

buck2202 commented Dec 30, 2021 •

edited

buck2202 commented Jan 22, 2022

My-Random-Thoughts commented Jan 22, 2022

buck2202 commented Jan 22, 2022 •

edited

buck2202 commented May 9, 2022 •

edited

LinuxOnTheDesktop commented Sep 11, 2022

buck2202 commented Sep 11, 2022

LinuxOnTheDesktop commented Sep 11, 2022

Long delay when opening Nemo / file dialogs #2497

Long delay when opening Nemo / file dialogs #2497

Comments

mikehaertl commented Aug 30, 2020 • edited

starsep commented Sep 6, 2020

Rinkaa commented Oct 7, 2020

My-Random-Thoughts commented Oct 15, 2020 • edited

mikehaertl commented Dec 11, 2020

icarter09 commented Dec 12, 2020

edupsousa commented May 21, 2021

RandomGHUser commented Jun 23, 2021

offset8 commented Aug 2, 2021

mikehaertl commented Oct 15, 2021

buck2202 commented Oct 15, 2021 • edited

buck2202 commented Oct 16, 2021

buck2202 commented Oct 16, 2021 • edited

buck2202 commented Oct 16, 2021

LinuxOnTheDesktop commented Dec 30, 2021

buck2202 commented Dec 30, 2021 • edited

LinuxOnTheDesktop commented Dec 30, 2021 • edited

buck2202 commented Dec 30, 2021 • edited

buck2202 commented Jan 22, 2022

My-Random-Thoughts commented Jan 22, 2022

buck2202 commented Jan 22, 2022 • edited

buck2202 commented May 9, 2022 • edited

LinuxOnTheDesktop commented Sep 11, 2022

buck2202 commented Sep 11, 2022

LinuxOnTheDesktop commented Sep 11, 2022

mikehaertl commented Aug 30, 2020 •

edited

My-Random-Thoughts commented Oct 15, 2020 •

edited

buck2202 commented Oct 15, 2021 •

edited

buck2202 commented Oct 16, 2021 •

edited

buck2202 commented Dec 30, 2021 •

edited

LinuxOnTheDesktop commented Dec 30, 2021 •

edited

buck2202 commented Dec 30, 2021 •

edited

buck2202 commented Jan 22, 2022 •

edited

buck2202 commented May 9, 2022 •

edited