Bug 506539
Summary: | homedirs blocked from ls -a after graphical login (kdm and gdm), because of faulty gvfs | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Herr Irrtum <wolfram.zieger+fedora> | ||||||
Component: | gvfs | Assignee: | Enrico Scholz <rh-bugzilla> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 11 | CC: | alexl, rh-bugzilla, tbzatek, wolfram.zieger+fedora | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-06-18 13:48:59 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 493565, 577927 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Herr Irrtum
2009-06-17 17:01:02 UTC
Created attachment 348309 [details]
an strace of ls -a stopping directly at the file .gvfs
This makes so much sense, but I did forgot about it in the first place. an strace of ls -la. And see what happens: ls stops exactly at looking up .gvfs
-
And furthermore: While I can "cat .bashrc" I can not "cat .gvfs" ."cat" simply stops responding.
So this seems to be the root of all evil .gvfs - I can not investigate more now, cause I have a son of 4 and he is hungry now :)
Will be back later (maybe)
I did forget to strace ls -la . Sorry. Now this is done and showing that the file .gvfs is causing the trouble. Ok - it's solved for me. I did deinstall gvfs - and *zack* I could ls -lA again in peace. Personally I am not interessted in *why* gvfs is failing, because in the first line I am a KDE user (after 3 years being bored to death by gnome :) could not resist to tell you :) ). However... some notes: If GVFS runs into a problem, it should not lead into the troubles of just blocking the whole homedir because a dynamic somewhat non functional .gvfs is there. It's like the gvfs devs try to hide this behind a nebulous mist where no one would think about GVFS as the trouble maker, cause any other trail which could lead to it is in a non functional state. I am sure that is not the case and hopefully just a unlucky coincidence. Aehem. Also I have to mention: Uninstalling GVFS per package kit GUI means also bye bye to Nautilus and the Mozilla Totem Plugins. Why that? I mean, the functionality of Nautilus is somewhat limited in an up to date Gnome Env without GVFS - but non functional? Sounds like Windows and MSIE. No reason to deinstall it imho. This is absolutely the case for the totem mozilla plugins. What has a multimedia player in a browser ever to deal with gvfs? Uninstalled automatically... I call that way bad packaging. Last thing. If gvfs is installed (as it is automatically in newer GNOMEs), why the heck has it to be activated when I start KDE? To put it in a fictional claim which of course is beyond reality but somewhat in the air (i.e. for the guys of the computer rainbow press): Why are gnome apps cowardly trying to shoot my KDE in the back? Well - umm - very last thing: There is the chance, that my SE Linux Actions (especially "seedit policy" which creates a completely new feature set, including renaming the original ini file in /etc/selinux, but also switching selinux completely off ["disabled"]) are the source of the faulty GVFS. This is something someone should check out. But not me - for me this day was rotten and I am glad my shiny KDE is doing it again... Regards. Herr Irrtum Thank you for the detailed feedback (and stories about the end of the world). This is the same issue as reported in bug 493565 and bug 503956. I'm going to close this one, feel free to add any of your comments to the bug 493565. This is caused by gvfs-fuse-daemon, resp. the active fuse mount in ~/.gvfs. Quick workaround can be either killing gvfs-fuse-daemon or removing the gvfs-fuse package. In fact, this looks like a deadlock somewhere between kernel and fuse. We're not facing this issue here, any clues leading to proper reproducer would be appreciated. One hint you could try is to run different kernel. One more thing: what does `gvfs-mount -l` say to you? (should be empty list unless you use some Gnome app). (In reply to comment #3) > Also I have to mention: Uninstalling GVFS per package kit GUI means also bye > bye to Nautilus and the Mozilla Totem Plugins. Why that? I mean, the > functionality of Nautilus is somewhat limited in an up to date Gnome Env > without GVFS - but non functional? Sounds like Windows and MSIE. No reason to > deinstall it imho. This is absolutely the case for the totem mozilla plugins. > What has a multimedia player in a browser ever to deal with gvfs? Uninstalled > automatically... I call that way bad packaging. GVFS is not a hard link-time dependency, you would only strip the VFS functionality completely and end up with local-only access. Nautilus would work that way (though it would not do any mount operations) but Totem and other apps are using various gvfs backend to access resources on the internet (e.g. http media streaming). This is why we made gvfs a hard dependency. The gvfs-fuse package is optional, only extending functionality to non-GIO applications, not affecting the GIO/GVFS system at all. It's been pulled in during Fedora installation (comps) and can be removed. Dependency hell is unfortunate, it's a common issue in Fedora. > Last thing. If gvfs is installed (as it is automatically in newer GNOMEs), why > the heck has it to be activated when I start KDE? This is more a question for the KDE team. AFAIK there's a KIO slave bridging GIO (resp. GVFS) to KDE. You may also have several common services running, like NetworkManager applet or Totem mentioned. > Well - umm - very last thing: There is the chance, that my SE Linux Actions > (especially "seedit policy" which creates a completely new feature set, > including renaming the original ini file in /etc/selinux, but also switching > selinux completely off ["disabled"]) are the source of the faulty GVFS. Switching SELinux off surely shouldn't cause these problems. *** This bug has been marked as a duplicate of bug 493565 *** Thanks lots of Tomáš, taking your time for this very detailed answer. Unbelievable in fact that you've answered this, considering this bug is a duplicate. In fact I was going to write something here right now, because today it occurred to me that I run in exactly the same problems when using sshfs. So I was about to point my fingers to fuse - and to apologize to the GVFS packagers... Was not that nice, what I had to tell about gvfs - especially when facing the fact, that fuse is the faulty thing here (which of course I did not realise yesterday...) So take my apologies and I am happy to read (or even comment if necessary) further in 493565. Thanks Tomáš and regards, Herr Irrtum |