search

linuxmint / nemo

File browser for Cinnamon
GNU General Public License v2.0
1.23k stars 300 forks source link

Long delay when opening Nemo / file dialogs #2497

Open mikehaertl opened 4 years ago

mikehaertl commented 4 years ago 
 * 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

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

Workaround

killall gvfsd-trash fixes the issue without a reboot.

starsep commented 4 years ago

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

Rinkaa commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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
RandomGHUser commented 3 years ago

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

offset8 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

buck2202 commented 3 years ago

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

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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.