Created attachment 3538 hacky test Hi, Since the migration to GIO, thunar is very slow to start: even if "Thunar --daemon" is launched with the session, the first Thunar window takes a lot of time to appear. I compared the list of processes running before and after launching Thunar, and the new ones are: * tumblerd * gvfsd-dnssd * gvfsd-network * gvfsd-smb-browser Tumblerd is ok, but the gvfsd network daemons don't make sense: everything is local in the main Thunar window (my home, my desktop, my special folders...). I compared with nautilus, and, as expected, these daemons don't run when I start it (and therefore it is fast to start), only when I click on the "Network" shortcut in the side pane. It seems the only difference between nautilus and thunar wrt the side pane is how shortcuts are managed: nautilus uses uris (strings), thunar gfiles. I made a quick test to try to figure out if these gfiles where an issue: I commented out the g_file_new_for_uri ("network://") codes in the thunar views (see attached patch^Whack). I rebooted to ensure it would be a cold launch, and thunar is now really fast to start. Moreover, gvfsd-{dnssd,network,smb-browser} are not spawned anymore when I only open $HOME. They are, however, correctly started when entering "network://" in the "Go to" bar. Since, apparently, g_file_new_for_uri ("network://") triggers the launch of all gvfs network-related daemons, even when you don't care and only want to browse $HOME, the solution to this slow first startup time might be to do like nautilus: use strings, and call g_file_new_for_uri (string) only when the shortcut has been clicked by the user. (of course, I might be completely wrong, and I've only tested on Xubuntu so far...) Thanks.
It's reproducible here. I guess we can allocate the network resources in an idle or timeout handler, kind of like you proposed.
(In reply to comment #0) > Created attachment 3538 > hacky test > > Hi, > > Since the migration to GIO, thunar is very slow to start: even if "Thunar > --daemon" is launched with the session, the first Thunar window takes a lot of > time to appear. > > I compared the list of processes running before and after launching Thunar, and > the new ones are: > * tumblerd > * gvfsd-dnssd > * gvfsd-network > * gvfsd-smb-browser > > Tumblerd is ok, but the gvfsd network daemons don't make sense: everything is > local in the main Thunar window (my home, my desktop, my special folders...). > > I compared with nautilus, and, as expected, these daemons don't run when I > start it (and therefore it is fast to start), only when I click on the > "Network" shortcut in the side pane. > > It seems the only difference between nautilus and thunar wrt the side pane is > how shortcuts are managed: nautilus uses uris (strings), thunar gfiles. > > I made a quick test to try to figure out if these gfiles where an issue: I > commented out the g_file_new_for_uri ("network://") codes in the thunar views > (see attached patch^Whack). I rebooted to ensure it would be a cold launch, and > thunar is now really fast to start. Moreover, gvfsd-{dnssd,network,smb-browser} > are not spawned anymore when I only open $HOME. They are, however, correctly > started when entering "network://" in the "Go to" bar. > > Since, apparently, g_file_new_for_uri ("network://") triggers the launch of all > gvfs network-related daemons, even when you don't care and only want to browse > $HOME, the solution to this slow first startup time might be to do like > nautilus: use strings, and call g_file_new_for_uri (string) only when the > shortcut has been clicked by the user. > > (of course, I might be completely wrong, and I've only tested on Xubuntu so > far...) > > Thanks. Yes even the same thing happened here on zenwalk 7.0 as well. Disabling the treeview shall make thunar load faster. Other wise slower. So will there be a fix soon for this? Also with this, i also observed that when i launch the thunar (command line or GUI) 2 windows opens up 1 after another. I dont know if its an zenwalk problem or XFCE.
Disabling the gdu monitor seems to resolve the issue (strace shows thunar, or more likely a library used by thunar: gio, is waiting for a dbus reply). During that time I don't see the trash or network daemons (ps -A | grep gvfs) only the gdu daemon. Now that doesn't mean network:// is slow, but it's not causing any delay on my system. So more is going on here, to problem is, what triggers the gdu monitor? g_volume_monitor?
*** Bug 7661 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Disabling the gdu monitor seems to resolve the issue (strace shows thunar, or > more likely a library used by thunar: gio, is waiting for a dbus reply). During > that time I don't see the trash or network daemons (ps -A | grep gvfs) only the > gdu daemon. I tried on my system and volumes in the shortcuts pane don't seem to slow things down for me. I have decided to delay adding the network item until the main loop is idle. As mentioned, there are other ways (only load strings + icons, resolve files only when items are clicked) but this seemed easiest to me. We can fix it for real when redesigning the shortcuts pane for 4.10. Here's the commit information (from master; I also applied it to the 4.8 branch): commit 5ce61f48171c9b95e8b89e0d2c53a7bfbeb9ac93 Author: Jannis Pohlmann <jannis@xfce.org> Date: Thu May 26 01:16:10 2011 +0200 Speed up initial start by adding the Network item later (bug #7313). There are other ways to achieve the same effect: load the icon and the name of items in the side pane first and only resolve the real files when users click on them. But this was easier. Also, I expect the side pane to be redesigned soon and this fix makes it easier to apply the change to the 4.8 branch.
Hi all, This bug still affects me after the last Thunar release (version 1.2.2), but now on a slightly different fashion: Thunar is starting normally (fast), but it stays unresponsive for about 15 seconds.
(In reply to comment #5) > commit 5ce61f48171c9b95e8b89e0d2c53a7bfbeb9ac93 I have built an experimental package of thunar 1.3.0 with a backport of this commit and according to a downstream reporter it did not fix the long delay (see https://bugzilla.novell.com/show_bug.cgi?id=684771#c10 for the downstream report).
Ok, I'll try another solution then.
I think the problem lies in volume loading/listing (is that what the gdu daemon does?), maybe we can do that async.
The gdu (gnome-disk-utility) daemon is the volume monitor, yeah. But 15 seconds of delay can only be caused by a slow network don't you think? In general though, that GIO/GVfs lauch so many D-Bus daemons is slowing Thunar down, so we probably need to find a solution that delays the network daemon, the volume monitor and others. Although I don't really want the window to be populated with stuff piece by piece with notable delays, that would be unpleasant.
There is a 5 sec timeout to wait for mount points (ie GVolume without a GMount) and to be honest, 5 seconds looks more reasonable on my pc. Renaming /usr/share/gvfs/remote-volume-monitors/gdu.monitor to gdu.monitor.foo made thunar appear instant. I agree the number-of-daemons problem should be resolved too, but that's not a huge delay.
In general, I'd suggest to have xfce4-session do some GVfs related initialization work in parallel to restoring the session. This doesn't save you from fixing stuff in Thunar, but it (a) makes sense and (b) works for 96.78% of all users. :-)
I agree it might work (however thunar --daemon could do that same), but I doubt this is something for the file manager.
Err. s/something for the file manager/something for the session manager/.
(In reply to comment #10) > The gdu (gnome-disk-utility) daemon is the volume monitor, yeah. But 15 seconds > of delay can only be caused by a slow network don't you think? > > In general though, that GIO/GVfs lauch so many D-Bus daemons is slowing Thunar > down, so we probably need to find a solution that delays the network daemon, > the volume monitor and others. Although I don't really want the window to be > populated with stuff piece by piece with notable delays, that would be > unpleasant. Here (Thunar 1.2.2 so with patch applied), starting fresh (no Thunar daemon, no gvfs process), running Thunar shows a window after about 2 secs and the Network item appears at around 4-5 sec.
Hi, for me that bug appeared again after an update. The first start is very slow. Thunar 1.2.3 Xfce 4.8 Xubuntu 11.10 Regards.
*** Bug 7749 has been marked as a duplicate of this bug. ***
I can also confirm that the bug has re-emerged. Xfce 4.8 Thunar 1.2.3 Ubuntu 11.10 Following a session login: Thunar takes about 30 seconds to load when launched. A second Thunar window appears a few seconds later. Subsequent thunar windows load without delay. Before the issue I had short-cuts on the sidebar to network locations. The short-cuts have now disappeared. I don't know if this is to do with the recent update or the bug.
I can confirm the bug. OS: Debian GNU/Linux, Wheezy Kernel: 3.0.0-1-486 Xfce4: 4.0.8.3 Thunar: 1.2.3-3 I began to experience the issue after some recent updates. I'm not sure of it, but most probably it was the "thunar (1.2.3-2) to 1.2.3-3 update" which I made on 18 February 2012; date it was served was close I believe. I see that libthunarx and thunar-data are updated during my same update. I found them searching the update history aginst thunar, because Thunar itself seems to be the number one suspect; the issue might be coming from another component as well.) What I experience is: -in the last 15-20 days, probably after an update- a) Thunar starts very slow b) It opens Thunar window twice: It opens the first and after a time (10-20 seconds, lets say) it opens the second. Both isssues are valid for the first time in a session. After then, if I close Thunar and open it again, it behaves normal. On https://bbs.archlinux.org/viewtopic.php?id=122836 is a archlinux bug report which seems similar to my situation. archlinux report mentioned above and my own experience involves a second window of Thunar (opens twice) but the original bug report before reopening does not tell anything about it, as far as I can see. I don't know if it makes this a new bug or not. As the friends who reopened and commented above, archlinux bug report points to this bug. In archlinux bug thread its not clear to me what thunar version did most of the reporters talk about so I can't comment that what they were talking and this bug is the same or not, but the symptoms are very similar. If to add: I don't experience anything like "folder could not be opened" as stated in arch bug report's title.
g_file_new_for_uri ("network://") seems to trigger something similar to gvfs-ls network: ; and this takes some time on the first run. So if you run gvfs-ls network: first, thunar starts immediately. This explains also why setting AutoMount=false in /usr/share/gvfs/mounts/network.mount works, because then gvfs-ls network: fails since network is not mounted. As a workaround one can run gvfs-ls network: before thunar starts. For a possible realization check https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/775117/comments/26 .
Hi, I'm using an up-to-date arch linux, and on my box thunar had no "first startup delay" until I installed wicd. Disabling wicd-client (the systray icon program) from xfce session, substituting "wicd" with "net-profiles" in the daemons array in /etc/rc.conf and rebooting made thunar first start no longer delayed. Since I didn't want to go back to netcfg, I reanabled it and found a workaround which consists in putting a "thunar+wicd_workaround.desktop" file into /etc/xdg/autostart with the following (...dirty, could certainly be less...) contents: [Desktop Entry] Encoding=UTF-8 Version=0.1 Type=Application Name=Workaround for wicd+thunar bug Comment=Brings down wicd created wired connection and brings it back up using netcfg Exec=sh -c "sudo netcfg down eth0; wicd-cli --wired -x; sudo netcfg up eth0" OnlyShowIn=XFCE; StartupNotify=false Terminal=false Hidden=false It works flawlessy on my box, allowing me to continue using wicd and thunar with no "first startup delay" and all the network browsing functions working. I also tried modifying it for a different scenario - automatic start of a wireless connection instead of a wired one - and it works, just changing the "Exec" line with this one: Exec=sh -c "sudo netcfg down eth1; wicd-cli --wireless -x; sudo netcfg up eth1" Obviously, if you want to try it, you have to substitute "eth0" or "eth1" with the name of a working netcfg "wired profile" or "wireless profile". The "Exec" line just drops the connection "as created by wicd" and brings it back using a "corresponding" netcfg profile; the additional prefixed "sudo netcfg down ..." makes this work on a session logout and re-login. Unfortunately netcfg has to be run through sudo with an appropriate (eg) "/etc/sudoers.d/netcfg" file set to let the user run at least the two "sudoed" netcfg commands without having to type in his-her password. I don't really know why it works :) , I guess it's maybe related to the probably different ways netcfg and wicd bring up an interface and/or a connection --- maybe wicd "binds" it to dbus and/or gvfs while netcfg doesn't, or they do it differently, or something like this... I'll try and check it when I'll have time. For now I just wanted to share the workaround, since maybe it can work on other boxes, or can be a suggestion for different workarounds and maybe for solving the thunar flaw. Bye
(In reply to comment #21) ...some corrections and additions... > I'm using an up-to-date arch linux, and on my box thunar had no "first > startup delay" until I installed wicd ...previously I was using netcfg to manage my net connenctions, and I still had it installed. > Disabling wicd-client (the systray > icon program) from xfce session, substituting "wicd" with "net-profiles" ...which is the rc.d script from netcfg... > in the daemons array in /etc/rc.conf and rebooting made thunar first start no > longer delayed. > Since I didn't want to go back to netcfg, I reanabled it ...substitute "it" with "wicd"... Also, this is the content of my /etc/network.d/eth0 profile: CONNECTION="ethernet" DESCRIPTION="Wired static ip connection" INTERFACE="eth0" IP="static" ADDR="192.168.1.3" GATEWAY="192.168.1.1" DNS=("192.168.1.1") ...and this is the content of my /etc/network.d/eth1 profile: CONNECTION="wireless" DESCRIPTION="Wireless static ip connection" WPA_DRIVER="nl80211" INTERFACE="eth1" SECURITY="wpa-config" WPA_CONF="/etc/wpa_supplicant.conf" IP="static" ADDR="192.168.1.3" GATEWAY="192.168.1.1" DNS=("192.168.1.1") ...maybe they can be useful to someone. Bye
*** Bug 8220 has been marked as a duplicate of this bug. ***
Can someone test this with 1.5.0, should be fixed.
Yeah, no more delay here, thanks.
*** Bug 8049 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > Can someone test this with 1.5.0, should be fixed. The commit log doesn't seem to contain a reference to this bug, could you point to the relevant commit(s)? Any idea if this is easily backportable?
Its implemented in a bunch of commits and nearly impossible to backport to 1.4.