You are not logged in.
Edit: see 3rd post for up to date information.
I tracked this problem down to this bug report from 2008 (which is itself a collection of different causes and symptoms):
https://bugs.launchpad.net/ubuntu/+sour … bug/218230
My symptoms:
Opening a GTK Open File Dialog takes around 30 seconds. The application is blocked during this period.
This ONLY happens the first time after each dbus restart. So once the first OFD pops up, everything is fine until I either reboot or restart dbus.
Output of dbus-monitor --system:
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.3"
string ""
string ":1.3"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.4"
string ""
string ":1.4"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.5"
string ""
string ":1.5"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.6"
string ""
string ":1.6"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string "org.freedesktop.UDisks"
string ""
string ":1.6"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.7"
string ""
string ":1.7"
<freeze happens here>
signal sender=:1.6 -> dest=(null destination) serial=8 path=/org/freedesktop/UDisks/devices/sdb2; interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.6 -> dest=(null destination) serial=9 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb2"
signal sender=:1.6 -> dest=(null destination) serial=10 path=/org/freedesktop/UDisks/devices/dm_2d0; interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.6 -> dest=(null destination) serial=11 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/dm_2d0"
signal sender=:1.6 -> dest=(null destination) serial=12 path=/org/freedesktop/UDisks/devices/sda; interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.6 -> dest=(null destination) serial=13 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sda"
signal sender=:1.6 -> dest=(null destination) serial=14 path=/org/freedesktop/UDisks/devices/sdb; interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.6 -> dest=(null destination) serial=15 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/sdb"
signal sender=:1.6 -> dest=(null destination) serial=17 path=/org/freedesktop/UDisks/devices/dm_2d0; interface=org.freedesktop.UDisks.Device; member=Changed
signal sender=:1.6 -> dest=(null destination) serial=18 path=/org/freedesktop/UDisks; interface=org.freedesktop.UDisks; member=DeviceChanged
object path "/org/freedesktop/UDisks/devices/dm_2d0"
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
string ":1.8"
string ""
string ":1.8"
I don't have any NFS mounts. The only atypical configuration is LVM partition.
I haven't been able to find any more infos about this. Is anybody else gettings this? Is there a known solution?
Last edited by schuay (2010-04-20 18:53:05)
Offline
I've noticed this on all my Arch machines since a major 100+ package pacman -Syu on the 18th. Still trying to track down the offending package, since I don't update as often as I used to. Downgrading GTK and dbus (and dbus-core) doesn't help.
Edit: I should add that I have no NFS mounts either. Nor LVM.
Last edited by dunc (2010-04-20 18:21:19)
0 Ok, 0:1
Offline
Looking at my dbus messages above, the following section from pacman.log looks very suspicious:
$ grep disk /var/log/pacman.log
[2010-03-26 22:57] installed devicekit-disks (009-5)
[2010-03-26 22:57] installed gnome-disk-utility (2.28.1-1)
[2010-04-01 07:52] removed devicekit-disks (009-5)
[2010-04-01 07:52] installed udisks (1.0.0-2)
[2010-04-01 07:53] upgraded gnome-disk-utility (2.28.1-1 -> 2.30.1-1)
[2010-04-10 11:07] upgraded udisks (1.0.0-2 -> 1.0.1-1)
No time currently to check if downgrading these helps. Also looks kinda complicated because udisks replaces devicekit-disks.
This also looks somehow related: http://groups.google.com/group/linux.de … 0f49cd9b53
Edit:
OK, the symptoms can be replicated with the following command sequence:
sudo /etc/rc.d/dbus restart
udisks --dump # <-- this takes forever.. 24 seconds on my system
udisks --dump # <-- any subsequent calls finish instantly, 0.043 seconds on my system
Last edited by schuay (2010-04-20 18:49:30)
Offline
I think we may be seeing a different issue. Or you've hit on the wrong diagnosis. Udisks --dump is instantaneous here no matter what.
0 Ok, 0:1
Offline
Hi,
OK, the symptoms can be replicated with the following command sequence:
sudo /etc/rc.d/dbus restart udisks --dump # <-- this takes forever.. 24 seconds on my system udisks --dump # <-- any subsequent calls finish instantly, 0.043 seconds on my system
I have the same problem: first time 30 seconds, second time instantaneous. That applies to pcmanfm2 and the common GTK file dialog.
I neither have any NFS mounts nor LVM partitions.
Offline
This could be way off but if you've hit a dead end it may be worth a shot. I had an issue where every time I opened up nautilus or an 'open/save file' dialog it would take ages. It turned out that the icon set I was using was causing the issue. nuoveXT2 I think it was. As soon as I switched to another everything got snappy again.
It might be worth ruling it out.
Offline
Well, how about that? CypherFTW is right, at least in my case. Stupid icons.
Edit: I was using MeliaeSVG, although probably an old version.
Last edited by dunc (2010-04-25 13:21:25)
0 Ok, 0:1
Offline
Not solved for me I still think it's something to do with udisks.
Offline
One thing that everyone needs to try when the GTK file chooser is misbehaving is the move, remove, or edit the gtk bookmarks file. I can't remember exactly what it's called, but it's something like ~/.gtk-bookmarks. It has a nasty tendency to keep garbage in it.
For instance, on my mother's Ubuntu box, there was a GTK bookmark to a flash drive. When the drive wasn't plugged in, GTK searched relentlessly for a non-existent file. Like the OP, it took around 30 seconds to open the dialog box. Removing the file in her case fixed it.
Offline
I don't seem to have that file,
~]$ find . -iname '*bookmark*'
only returns kde and firefox related results.
I also get the delay when calling 'udisks --dump' (see 3rd post in this thread) which - afaik - has nothing to do with gtk or file dialogs.
Somehow I seem to be the only one getting this issue..
Offline
I don't seem to have that file,
~]$ find . -iname '*bookmark*'
only returns kde and firefox related results.
I also get the delay when calling 'udisks --dump' (see 3rd post in this thread) which - afaik - has nothing to do with gtk or file dialogs.
Somehow I seem to be the only one getting this issue..
You're not alone!!
I also think that the problem comes from udisks, cause I have the same problem with that command
Offline
galerote, do you have an ssd by any chance?
Offline
galerote, do you have an ssd by any chance?
No, I don't.
Offline
same problem here. running x86_64.
Offline
replacing fam with gamin always made big impact here.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
I solved the problem, turns out that udisk was attempting to read /dev/fd0, but I do not have a floppy drive.
I disabled the floppy drive in the BIOS, and the problem went away.
Offline
I solved the problem, turns out that udisk was attempting to read /dev/fd0, but I do not have a floppy drive.
I disabled the floppy drive in the BIOS, and the problem went away.
Awesome, that's it
Edit: and here's the ubuntu bug report, seems like this is already known: https://bugs.launchpad.net/ubuntu/+sour … bug/539515
Last edited by schuay (2010-04-26 16:43:10)
Offline
I solved the problem, turns out that udisk was attempting to read /dev/fd0, but I do not have a floppy drive.
I disabled the floppy drive in the BIOS, and the problem went away.
It worked
Thank you.
Offline
I also had this issue - GTK file chooser and Nautilus took more than 20 seconds to open. However, I run my system on laptop, which doesn't even have ability to set you floppy drive in BIOS (obviously).
Problem lied elsewhere - in GVFS. After i got rid of it, everything turned back to normal. Of course, not everyone can afford this, since GVFS is an important dependency for many GNOME package, such as Nautilus.
Offline
From the Ubuntu bug report:
I uploaded a potential udisks fix to my SRU test PPA:
https://launchpad.net/~pitti/+archive/sru-test
Can you please upgrade to that and check if it helps? Thanks!
--
probing a non-existing floppy causes long boot delays
https://bugs.launchpad.net/bugs/539515
...aand upstream fix here: http://cgit.freedesktop.org/udisks/comm … e2cca44164
Last edited by schuay (2010-06-02 14:47:20)
Offline
I solved the problem, turns out that udisk was attempting to read /dev/fd0, but I do not have a floppy drive.
I disabled the floppy drive in the BIOS, and the problem went away.
yes, it works
thanks
Offline
As mentioned in tons of other threads about GNOME (for example the long startup time) you should really disable the floppy module by putting
!floppy in /etc/rc.conf in the modules array when you use the GNOME Desktop.
Especially people who dont have any floppy drives. I dont know if this is a problem of GNOME or Udisk or more a problem from users who just dont care about what modules are loaded on there systems
Offline
Especially people who dont have any floppy drives. I dont know if this is a problem of GNOME or Udisk or more a problem from users who just dont care about what modules are loaded on there systems
Disabling the floppy module is a workaround. The real issue is with udisks (up to and including 1.0.1) as was mentioned several times in this thread.
Last edited by schuay (2010-06-16 12:51:10)
Offline
So loading the floppy module even when there is no floppy avaible is correct but when udisk starts struggling in case of that its the fault of udisk?
Offline