[Bug 634554] Re: fuse mounts hang on xattr retrieval with auditd
Bug Watch Updater
634554 at bugs.launchpad.net
Fri Oct 27 01:07:11 UTC 2017
Launchpad has imported 122 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=493565.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-04-02T09:39:58+00:00 Mamoru wrote:
Created attachment 337759
tarball containing ps auwwx, .xsession-errors log
Description of problem:
With the following procedure:
[1] Reboot with init 3. On tty1 log in as root
[2] On tty1, type # init 5 as root, then GDM launches
[3] With GDM log in as non-root user to GNOME session
[4] log out from GNOME session
[5] Again log in to GNOME session as the same user on [3]
Then GNOME session hangs.
Version-Release number of selected component (if applicable):
gvfs-1.2.0-2.fc11.i586
fuse-2.7.4-3.fc11.i586
How reproducible:
Currently 100%
Steps to Reproduce:
1. See above
2.
3.
Additional info:
- The results of "ps auwwx" on each stage [1] - [5] and .xsession-errors
are in the attached tarball
- On the stage [4], when I kill the process 3576 and 3578
with SIGKILL, the second login to GNOME works.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/0
------------------------------------------------------------------------
On 2009-04-02T12:52:56+00:00 Tomáš wrote:
Just tested according to the repro steps provided, works for me. Tested
with newly created account as well as with my old personal account.
>From your logs, I can see possible point of failure:
gnome-session[4402]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout
gnome-session[4402]: WARNING: Application 'gnome-panel.desktop' failed to register before timeout
(imsettings-applet:4548): IMSettings-WARNING **: メソッド WhatsInputMethodRunning' の呼出に失敗しました : Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
(gnome-panel:4537): GVFS-RemoteVolumeMonitor-WARNING **: invoking
IsSupported() failed for remote volume monitor with dbus name
org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.NoReply:
Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply,
the reply timeout expired, or the network connection was broken.
Looks like dbus is not running in the session. Can you post `rpm -qa | grep -e dbus -e glib2` here?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/1
------------------------------------------------------------------------
On 2009-04-02T13:04:36+00:00 Mamoru wrote:
Hi:
[tasaka1 at localhost ~]$ rpm -qa | grep -e dbus -e glib2 | sort
dbus-1.2.12-1.fc11.i586
dbus-debuginfo-1.2.12-1.fc11.i586
dbus-devel-1.2.12-1.fc11.i586
dbus-glib-0.80-2.fc11.i586
dbus-glib-debuginfo-0.80-2.fc11.i586
dbus-glib-devel-0.80-2.fc11.i586
dbus-libs-1.2.12-1.fc11.i586
dbus-python-0.83.0-5.fc11.i586
dbus-x11-1.2.12-1.fc11.i586
glib2-2.19.10-2.fc11.i586
glib2-debuginfo-2.19.10-2.fc11.i586
glib2-devel-2.19.10-2.fc11.i586
pulseaudio-libs-glib2-0.9.15-8.test7.fc11.i586
python-slip-dbus-0.1.15-3.fc11.noarch
ruby-glib2-0.18.1-6.fc11.i586
ruby-glib2-devel-0.18.1-6.fc11.i586
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/2
------------------------------------------------------------------------
On 2009-04-02T13:35:32+00:00 Tomáš wrote:
Can you try upgrading to glib2-2.20.0-1.fc11? I doubt it will make any
difference, but just to be sure.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/3
------------------------------------------------------------------------
On 2009-04-02T13:36:43+00:00 Tomáš wrote:
(In reply to comment #3)
> Can you try upgrading to glib2-2.20.0-1.fc11? I doubt it will make any
> difference, but just to be sure.
Oh, that build is failed, disregard my comment, my mistake.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/4
------------------------------------------------------------------------
On 2009-04-02T14:58:25+00:00 Tomáš wrote:
Can you please check selinux status? (getenforce)
Also please check dmesg for any segfaults and avc denials.
We had some troubles with gvfs-fuse-daemon not exiting after logout, but
it shouldn't cause failures on second login. I don't see anything like
3576 (fusermount) or 3578 (mount) here, make sure you don't have
anything like this in /etc/fstab.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/5
------------------------------------------------------------------------
On 2009-04-02T17:31:24+00:00 Mamoru wrote:
[tasaka1 at localhost ~]$ getenforce
Disabled
My fstab is:
-----------------------------------------------------
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
/dev/VolGroup00/LogVol02 /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=/tmp /tmp ext3 defaults 1 2
/dev/VolGroup00/LogVol01 /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
/dev/sda6 swap swap defaults 0 0
#/dev/sda2 /mnt/Windows-VFAT vfat noauto,owner,user,codepage=932,iocharset=euc-jp,posix,umask=0022 1 2
#/dev/sda1 /mnt/Windows-NTFS-3g ntfs-3g noauto,ro,locale=ja_JP.UTF-8 0 0
------------------------------------------------------
( Now I commented out the last 2 lines but the result is the
same )
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/6
------------------------------------------------------------------------
On 2009-04-03T08:27:47+00:00 Alexander wrote:
Its kinda weird that you see the fusermount and mount processes after
the first login. These are supposed to be shortlived things that run and
exit, only gvfs-fuse-daemon should be running for any longer period.
So, it seems to me that the process of mounting the fuse filesystem on
~/.gvfs somehow hangs.
Maybe you could try attaching to the fusermount and/or mount processes
and get a backtrace?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/7
------------------------------------------------------------------------
On 2009-04-03T12:57:36+00:00 Tomáš wrote:
Can you try the following in your first running session? Mount some ftp
or sftp filesystem using Nautilus, make sure you can browse it. Then go
to ~/.gvfs, you should see those mounts there. Check again if you can
browse the mounts. I was wondering if the gvfs-fuse-daemon works as
expected for you.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/8
------------------------------------------------------------------------
On 2009-04-03T14:04:06+00:00 Mamoru wrote:
Created attachment 338039
screenshot of nautilus
First for this:
(In reply to comment #8)
> Can you try the following in your first running session? Mount some ftp or sftp
> filesystem using Nautilus, make sure you can browse it. Then go to ~/.gvfs, you
> should see those mounts there. Check again if you can browse the mounts. I was
> wondering if the gvfs-fuse-daemon works as expected for you.
Well, the actual result for this is:
When I launch $ nautilus from uxterm:
- nautilus won't show the contents of my home directory.
(please see the attached png file)
When I move the mouse pointer on nautilus, the mouse pointer
shows it is still under processing.
- By "File -> Connect to Server" (I guess, my locale is ja_JP),
mounting ftp server succeeds.
- I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
first
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/9
------------------------------------------------------------------------
On 2009-04-03T14:20:59+00:00 Mamoru wrote:
Created attachment 338049
gdb log
And gdb log is attached.
Note:
For process 3707, when trying to attach this process,
gdb itself hangs, so I had to kill gdb.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/10
------------------------------------------------------------------------
On 2009-04-03T15:07:49+00:00 Mamoru wrote:
Created attachment 338060
ps auwwx when logged in GNOME session with kernel 2.6.27.x
(In reply to comment #7)
> Its kinda weird that you see the fusermount and mount processes after the first
> login. These are supposed to be shortlived things that run and exit, only
> gvfs-fuse-daemon should be running for any longer period.
Well, I tried to reboot with kernel-2.6.27.21-170.2.56.fc10.i686
and actually
- 2nd login to GNOME succeeds
- There are no "fusermount" "mount" process
[GOOD] kernel-2.6.27.21-170.2.56.fc10.i686
[BAD ] kernel-2.6.29.1-35.rc1.fc11.i586
[BAD ] kernel-2.6.29.1-46.fc11.i586
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/11
------------------------------------------------------------------------
On 2009-04-03T15:12:10+00:00 Mamoru wrote:
Created attachment 338061
dmesg (2.6.29.1-46.fc11.i586)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/12
------------------------------------------------------------------------
On 2009-04-03T15:23:19+00:00 Tomáš wrote:
(In reply to comment #11)
> Well, I tried to reboot with kernel-2.6.27.21-170.2.56.fc10.i686
> and actually
> - 2nd login to GNOME succeeds
> - There are no "fusermount" "mount" process
>
> [GOOD] kernel-2.6.27.21-170.2.56.fc10.i686
> [BAD ] kernel-2.6.29.1-35.rc1.fc11.i586
> [BAD ] kernel-2.6.29.1-46.fc11.i586
Good catch, 2.6.29-21.fc11.x86_64 here, no problems with fuse.
(In reply to comment #9)
> - nautilus won't show the contents of my home directory.
> (please see the attached png file)
> When I move the mouse pointer on nautilus, the mouse pointer
> shows it is still under processing.
This is weird. Were there any nautilus errors on the uxterm shell? Could be
broken thumbnailer, but that should not make Nautilus unusable.
> - I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
> first
You can use other tools, like mc (Midnight Commander) in a terminal or bash
commands
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/13
------------------------------------------------------------------------
On 2009-04-03T16:33:49+00:00 Mamoru wrote:
Created attachment 338081
nautilus output on terminal
With 2.6.29.1-46.fc11.i586:
(In reply to comment #13)
> (In reply to comment #11)
> (In reply to comment #9)
> > - nautilus won't show the contents of my home directory.
> > (please see the attached png file)
> > When I move the mouse pointer on nautilus, the mouse pointer
> > shows it is still under processing.
> This is weird. Were there any nautilus errors on the uxterm shell? Could be
> broken thumbnailer, but that should not make Nautilus unusable.
nautilus output is attached here.
> > - I don't know how to go to ~/.gvfs on nautilus, because of the issue I wrote
> > first
> You can use other tools, like mc (Midnight Commander) in a terminal or bash
> commands
Well, actually I tried
$ ls -al ~/.gvfs
$ cd ~/.gvfs
but they all hang... It seems that nautilus is hanging just
because nautilus cannot access to ~/.gvfs
By the way with kernel 2.6.27.21-170.2.56.fc10.i686
--------------------------------------------------------
$ ls -al ~/.gvfs
合計 24
dr-x------ 3 tasaka1 tasaka1 0 2009-04-04 01:06 .
drwx------. 244 tasaka1 tasaka1 20480 2009-04-04 01:06 ..
drwx------ 1 tasaka1 tasaka1 0 1970-01-01 09:00 ftp %28ftp.riken.go.jp%29
--------------------------------------------------------
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/14
------------------------------------------------------------------------
On 2009-04-06T08:11:22+00:00 Alexander wrote:
Hmm, it seems like there is something wrong in the kernel wrt fuse
mounts. But I don't see anything weird in the dmesg output.
Any chance you could try various kernel versions to try to figure out
the first broken one?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/15
------------------------------------------------------------------------
On 2009-04-07T16:34:04+00:00 Mamoru wrote:
Umm.. After installing various old kernel and updating
rpms, suddenly I got unable to reproduce this issue even with
kernel-2.6.29.1-52.fc11.i586, kernel-2.6.29.1-54.fc11.i586 ????
I don't know what actually changed, however currently
2nd login to GNOME works...
If it is still impossible for me to reproduce this issue
within 2 days, I will close this bug...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/16
------------------------------------------------------------------------
On 2009-04-14T16:44:31+00:00 Mamoru wrote:
Once close this bug, thanks.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/17
------------------------------------------------------------------------
On 2009-04-23T14:59:41+00:00 Eric wrote:
mount S ffff8801356bc340 0 2506 2499
ffff8800b194fc18 0000000000000086 0000000002362000 0000000081878430
ffff8800b194fc68 ffffffff8178a380 ffff8800b1f40380 ffff8800b1f40380
ffffffff8178a380 0000000100000696 ffff88012c091720 ffff8800b1f40000
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd
[<ffffffff810df628>] ? path_put+0x22/0x26
[<ffffffff810dfbf4>] audit_inode+0x28/0x2a
[<ffffffff810e18f9>] do_path_lookup+0x150/0x173
[<ffffffff810e2dfc>] user_path_at+0x56/0x93
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff810db03c>] sys_readlinkat+0x2d/0x91
[<ffffffff813b02bc>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810db0bb>] sys_readlink+0x1b/0x1d
[<ffffffff810113ba>] system_call_fastpath+0x16/0x1b
bash S ffff880138c6a700 0 2922 2896
ffff88009f3dbba8 0000000000000086 00000000069f3000 0000000081879530
ffff88009f3dbbf8 ffffffff8178a380 ffff88009f1f1aa0 ffff88009f1f1aa0
ffffffff8178a380 00000001000006c6 ffff8800ad8fae40 ffff88009f1f1720
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd
[<ffffffff810df628>] ? path_put+0x22/0x26
[<ffffffff810dfbf4>] audit_inode+0x28/0x2a
[<ffffffff810e18f9>] do_path_lookup+0x150/0x173
[<ffffffff810e2dfc>] user_path_at+0x56/0x93
[<ffffffff813b043a>] ? _spin_lock+0xe/0x11
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff810db1a0>] ? cp_new_stat+0xe3/0xf0
[<ffffffff810db517>] vfs_stat_fd+0x24/0x4f
[<ffffffff810db5b5>] sys_newstat+0x27/0x41
[<ffffffff8108a89e>] ? audit_syscall_entry+0x11e/0x14a
[<ffffffff813b02bc>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810113ba>] system_call_fastpath+0x16/0x1b
lsof S ffff88006792bc28 0 3492 1
ffff88006792bc18 0000000000000082 ffff8800280403f0 0000000081879530
ffff88006792bc68 ffffffff8178a380 ffff88006ccb31c0 ffff88006ccb31c0
ffffffff8178a380 00000001000006c6 ffff88013aa9c560 ffff88006ccb2e40
Call Trace:
[<ffffffff8102bfb3>] ? default_spin_lock_flags+0x9/0xe
[<ffffffffa03a3afb>] fuse_get_req+0xc1/0x166 [fuse]
[<ffffffff8105ec23>] ? autoremove_wake_function+0x0/0x39
[<ffffffffa03a41e6>] fuse_getxattr+0x58/0x14f [fuse]
[<ffffffff810ecd57>] ? mntput_no_expire+0x36/0x150
[<ffffffff8118189a>] get_vfs_caps_from_disk+0x52/0xcd
[<ffffffff810df522>] ? path_to_nameidata+0x29/0x3e
[<ffffffff81088381>] audit_copy_inode+0x83/0xb1
[<ffffffff810888c7>] __audit_inode+0x1ee/0x1fd
[<ffffffff810df628>] ? path_put+0x22/0x26
[<ffffffff810dfbf4>] audit_inode+0x28/0x2a
[<ffffffff810e18f9>] do_path_lookup+0x150/0x173
[<ffffffff810e2dfc>] user_path_at+0x56/0x93
[<ffffffff810d779f>] ? fsnotify_access+0x64/0x6c
[<ffffffff810db03c>] sys_readlinkat+0x2d/0x91
[<ffffffff813b02bc>] ? trace_hardirqs_on_thunk+0x3a/0x3c
[<ffffffff810db0bb>] sys_readlink+0x1b/0x1d
[<ffffffff810113ba>] system_call_fastpath+0x16/0x1b
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/18
------------------------------------------------------------------------
On 2009-04-29T02:34:09+00:00 Chuck wrote:
fs/fuse/dev.c:104
intr = wait_event_interruptible(fc->blocked_waitq, !fc->blocked);
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/19
------------------------------------------------------------------------
On 2009-05-11T17:27:54+00:00 Jesse wrote:
The reporter asked for this bug to be closed, so I'm going to close it.
If this is still happening with current kernels
(kernel-2.6.29.2-126.fc11 or newer) please re-open.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/20
------------------------------------------------------------------------
On 2009-05-11T17:37:09+00:00 Eric wrote:
reopening once again, it still happens. Happening on kernels as late as
2.6.30-rc5-next-20090511 if that's new enough for you.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/21
------------------------------------------------------------------------
On 2009-05-11T18:28:50+00:00 Jesse wrote:
(In reply to comment #21)
> reopening once again, it still happens. Happening on kernels as late as
> 2.6.30-rc5-next-20090511 if that's new enough for you.
Can you clarify the scenario needed to reproduce this issue? So far it
seems that only the two if you in this bug (and now only you) are seeing
this issue, so I'm going to have a hard time leaving this on the blocker
list.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/22
------------------------------------------------------------------------
On 2009-05-11T19:16:34+00:00 Eric wrote:
Can't explain it at all. I've had it happen on both of the last 2 F11
installs I did. Never seemed to do it to start with and then pop, it
would start to happen. I reinstalled with the exact same set of package
out of rawhide and it would work for a while. Then it would come
back.... Updating/changing kernels obviously has no affect....
If you see fusermount and mount after you are logged in you hit the
problem...
-Eric
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/23
------------------------------------------------------------------------
On 2009-05-18T18:33:22+00:00 Jesse wrote:
I don't think we have enough information about this issue to really
block the release. It is annoying yes, and we'll want to get it fixed,
but I don't think we'll hold the release for this issue.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/24
------------------------------------------------------------------------
On 2009-05-18T18:35:18+00:00 James wrote:
eparis: Could this related to your authentication/user_info settings?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/25
------------------------------------------------------------------------
On 2009-05-18T19:08:36+00:00 Eric wrote:
The only thing interesting about my user is that I have it as an selinux
confined user, staff_u
semanage login -a -s staff_u -r s0-s0:c0.c1023 eparis
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/26
------------------------------------------------------------------------
On 2009-06-09T13:04:56+00:00 Bug wrote:
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/27
------------------------------------------------------------------------
On 2009-06-18T13:48:59+00:00 Tomáš wrote:
*** Bug 506539 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/28
------------------------------------------------------------------------
On 2009-06-18T13:49:41+00:00 Tomáš wrote:
Several interesting comments can be found in bug 506539
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/29
------------------------------------------------------------------------
On 2009-06-18T13:58:18+00:00 Eric wrote:
Just so people know, as root, if you kill -9 both the 'mount' and
'fusermount' process, everything starts to work just fine. Need to find
a way to strace the mount/fusermount. But I reinstalled and it went
away. I'm sure it'll come back....
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/30
------------------------------------------------------------------------
On 2009-06-18T17:33:58+00:00 Herr wrote:
Hi there, I am the guy from ex Bug 506539.
It is pretty clear, that it's any fuse thing which can cause this hang of things which want to read the fuse-mounted directorys - i.e. also sshfs.
So I just straced sshfs as root, mounting user blub of
moviestation:/home/blub into /root/temp/huch (in the middle I had to
enter the password, until this part it works, after entering the
password it pukes a lot more into the strace output file and stops when
it tries to access the freshly created mountpoint, at least this is
where the strace stops as you can see). For the hackerkiddies out there:
Its a dummy user with a dummy password on a dummy machine running on
freebsd.
Maybe this helps a bit (I am absolutely not the one who is able to
interpret that strace stuff - so maybe the whole action is a bit naive).
I mean - err - fuse just *has* to work! Really! (But you know this
already I guess :) )
What's also interesting. I know for sure that sshfs did work right after installing fedora 11, also after installing that famous first 110 MB updates (reduced to bits by presto), and so did gvfs.
That would mean nothing less than this is *not* kernel related in the first line. Maybe other kernel modules start to fight back after a while, I dunno.
I will hang in the strace output file of my sshfs experiment within the next minutes.
Regards, Herr Irrtum
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/31
------------------------------------------------------------------------
On 2009-06-18T17:36:38+00:00 Herr wrote:
Created attachment 348532
straced output of sshfs as root which fails to mount something
straced output of sshfs as root, mounting user blub of
moviestation:/home/blub into /root/temp/huch
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/32
------------------------------------------------------------------------
On 2009-06-18T20:28:36+00:00 Eric wrote:
hmmm, not as interesting as I might have hoped. Can you do with with -f
added to strace?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/33
------------------------------------------------------------------------
On 2009-06-19T08:17:14+00:00 Herr wrote:
(In reply to comment #33)
> hmmm, not as interesting as I might have hoped. Can you do with with -f added
> to strace?
it was already straced with -f, sorry.
But some new brain storm fodder:
I tried it once more in a slightly different setting (as user, which is the mail purpose of fuse - not as root)
Fusemount did hang as usually so I had to kill it (did that as root).
And then there was a interesting output on the user console:
>fusermount: failed to access mountpoint /home/xxxxx/xxxx/temp: Permission denied
You have to know, I created temp as a user , just "mkdir temp" so permissions looked like this before usermount:
>drwxrwxr-x 2 user usergroup 4096 19. Jun 09:58 temp
Now after killing any fuse process, permissions look different:
>d?????????? ? ? ? ? ? temp
errr?!
This reminds me of things years ago: To use fusermount as a user, the user has to be in a group, fuse.
Is this still the case, especially on fedora?!
On my system, there is no group "fuse". and so my user is not part of this.
My user is not even part of "users" its just user: username(500); prim.group: username(500) and additionally group: vboxusers.
But fuse is even failing under "root", so this is probably not something to hunt down in the first line.
Anyway, researching more about this, I stumbled upon this:
<https://bugs.launchpad.net/ubuntu/+source/sshfs-fuse/+bug/123501>
where someone is pointing out, that /dev/fuse should have the right
permissions set.
Mine is
>crw-rw-rw- 1 root root 10, 229 19. Jun 2009 /dev/fuse
For me this looks quite sane at least to make fuse to work for root.
.
Enough bubbling.
------------------------------------------------------------------------------
The priority question is: Why is fuse changing the permissions of a mount point to
>>d?????????? ? ? ? ? ? mountpoint
permanently, even after killing all fuse processes?
------------------------------------------------------------------------------
What I personally wonder is, if a fuse group is necessary on fedora (I
guess, no).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/34
------------------------------------------------------------------------
On 2009-06-26T21:34:22+00:00 Herr wrote:
+++ Solution ++++ Solution +++ Solution ++++
I can not cry it out loud enough - sorry for a slightly notable
enthusiasm overkill :) - but I found the solution (it is not *exactly*
the source of it, but in a unspecific way it is).
Today I got a new regular kernel per yum update.
Tried out sshfs - still the same.
Now I did again some research - and all in all it is really easy - you
only need to know how fuse ticks to get to the solution.
Fuse is "file system in userspace". It relies heavily on sysfs, which just makes something like a file system in userspace possible at least.
But sysfs at fedora is not something you get as a "single app" it is just a lib which is used by... udev.
So basically udev (something like a "device in userland") makes fuse
possible.
So I just did
>yum reinstall udev
rebooted just in case.
And that was it!
Fuse works in all it's beauty.
Regards,
Herr Irrtum
PS. One question remains: What did alter udev in such a bad way?! If I
find out, I'll post it (but I hope I never will experience this again)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/35
------------------------------------------------------------------------
On 2009-06-28T18:38:51+00:00 Herr wrote:
I think I found what is causing this udev problem.
The suspicious thing is the virtual box kernel module - but I am not
sure if it is really to blame - because if I remove it from the services
(so lsmod does not list it) and even remove it's udev ruleset entry
under /etc/udev/rules.d (and rebooting) fuse does not come back to live.
So at the moment I can't use fuse, and I don't know how to re enable it
- even reinstalling udev does not work for now.
Why do I find Virtual box suspicious?
At first, when I talk about virtual box, I mean the "Personal Use and
Evaluation License" edition - installed from the fedora rpm at the vbox
website - not the OSE edition from rpmfusion!
The normal mechanism is:
When getting a new kernel via yum update, self compiled kernel modules like "vboxdrv" have to be compiled again.
So when I got my last kernel update, the virtual box kernel module (in
short "vboxdrv") did not load because it was build for the old kernel. I
was not aware of this because I don't use virtual box all the time.
After reinstalling udev, fuse did work again (as described in my last
post here).
But after a time I had to use virtual box, had to compile vboxdrv again (this is archived almost automatically by activating a script via "/etc/init.d/vboxdrv setup").
Now it took some time that I had to use fuse again - and to discover it does not work again. So the only new kernel module I did install for sure was vboxdrv.
The thing which speaks against my theory is, that removing vboxdrv from
the init scripts and removing it's ruleset from udev does not help. In
the beginning of my bug reports (before the kernel update) I even did
uninstall the whole vbox package (because this was supposed in some
forum), which did not help either.
So maybe it is the script which starts when doing "/etc/init.d/vboxdrv
setup" and doing something strange... but I do not have time right now
to look at it.
Can someone confirm this correlation with Virtual Box, or even confirm
if compiling any "own" kernel modules may disturb fuse or udev?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/36
------------------------------------------------------------------------
On 2009-07-13T12:38:19+00:00 Peter wrote:
I have this appear on a fresh installation of F11 x86_64. I can rmdir
the ~/.gvfs using the rescue disk, but a few days later, it again
becomes inaccessible and causes programs to hang trying to stat()
~/.gvfs.
Not running Virtual Box or custom kernel.
Are there any particular tests or logs you'd like run/collected to get
to the bottom of this?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/37
------------------------------------------------------------------------
On 2009-07-20T15:45:54+00:00 Tomáš wrote:
*** Bug 510870 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/38
------------------------------------------------------------------------
On 2009-07-22T08:13:57+00:00 Tomáš wrote:
*** Bug 513050 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/39
------------------------------------------------------------------------
On 2009-07-30T10:08:12+00:00 J. wrote:
I get this bug without VirtualBox installed, but on the other hand, I do
have VMware. But I wasn't running it at the time, and I haven't even
been able to compile the kernel modules for this new kernel yet, so they
couldn't have been loaded. On the other hand, I do have the RPMfusion
akmods and akmod-nvidia-173xx, plus their own kmod-nvidia-173xx
packages, giving me extra kernel modules. Currently using kernel-
PAE-2.6.29.6-213.fc11.i686, gvfs-1.2.3-8.fc11.i586,
fuse-2.7.4-3.fc11.i586, udev-141-4.fc11.i586, and kmod-nvidia-
173xx-2.6.29.6-213.fc11.i686.PAE-173.14.18-2.fc11.11.i686.
And just to add a bit to why this needs to be fixed, this has been
causing things like mlocate's daily updatedb and the daily rkhunter to
hang when they hit the user's directory, so for example my mlocate.db
hasn't been successfully updated since the 24th. And when I realize
this is happening again, I have to go through the process list, kill-
9ing updatedb and rkhunter process left and right.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/40
------------------------------------------------------------------------
On 2009-08-21T09:08:22+00:00 Dimitris wrote:
Plain clean F11 installation, same problem here.
I first noticed it two days after a clean install, the gnome file
manager freezes when opening the home (and only the home) directory.
I killed all gvfs related processes, reinstalled udev (as the poster in
comment #35 and so far its working ok.
There is definitely something wrong here.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/41
------------------------------------------------------------------------
On 2009-08-24T15:11:28+00:00 Michael wrote:
Ok - and let me add...
Today I noticed that cron.daily had stopped running. The cron error log
said that /etc/cron.daily was locked by another process... seemed
simple, until lsof /etc/cron.daily also hung.
I was rather perplexed. lsof without parameters also hung. Turned off
selinux (setenforce 0) ... same issue.
did strace lsof /etc/cron.daily... low and behold, last line was a
user's /home/<user>/.gvfs.
Killed all the mounts (fusermount, mount, daemon, etc.) and anacron
kicked right in and started running the overdue jobs.
Needless to say, that user space activities affect system administrative
functions isn't really a good thing.
I have looked at the upstream bug reports, and would suggest absent the
necessary upstream philosophical changes that fedora disable the feature
by default.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/42
------------------------------------------------------------------------
On 2009-08-31T14:11:27+00:00 Eric wrote:
*** Bug 517946 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/43
------------------------------------------------------------------------
On 2009-08-31T14:12:57+00:00 Eric wrote:
After playing with some seedit utilities I ended up unable to use any fuse file
systems. Trying to mount a fuse system would just freeze along the way leaving
the mount point in an intermediate state. For example trying to do
ls ~/.gvfs
would just hang. Another consequence is that nautilus would freeze when trying
to look at my home directory (because of the presence of .gvfs)
After a lot of exploration I found that the culprit was the audit service and
in particular a rule that got added by some utilites along the way.
Removing this rule fixed the problem. After this all fuse mount started to work
again.
I guess this is probably a kernel bug...
Comments from BZ 517946:
I know I have audit rules loaded (auditctl -l) how many other people
who are experiencing this problem have audit rules loaded?
Version-Release number of selected component (if applicable):
Fedora 11
audit-1.7.13-1.fc11
a bunch of kernels:
kernel-2.6.29.4-167.fc11.i586, kernel-2.6.29.6-217.2.7.fc11.i586
How reproducible:
Always
Steps to Reproduce:
1. have the the following rule in /etc/audit/audit.rules
-a exit,always -S chroot
2. have the auditd service started
3. Try to mount any fuse filesystem (logging in in gnome will try to mount
~/.gvfs)
4. Any access to the mount will block, for example try:
ls ~/.gvfs
5. Also note that some additional processes are left running (like a mount -i
...)
Actual results:
The ls just hangs there and does not return to the shell unless it is killed.
Expected results:
The ls should run normally, display results (maybe nothing) and return to the
shell.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/44
------------------------------------------------------------------------
On 2009-08-31T15:18:48+00:00 Michael wrote:
FWIW, I do have that audit rule as well. Haven't tried removing as I've
removed gvfs.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/45
------------------------------------------------------------------------
On 2009-08-31T22:47:52+00:00 Herr wrote:
(In reply to comment #44)
Hi Eric,
thanks a lot - you did a hell of a detectives job finding out about that auditd service (which I never ever would have suspected - I thought it just "collects security related events in a dedicated audit log" as i.e. system-config-services is hinting).
Anyway: Just commenting out that...
"# -a exit,always -S chroot"
...line from /etc/audit/audit.rules and restarting the daemon did not
help here (but maybe "/etc/init.d/auditd restart" isn't strict enough).
However...
*brutally halting auditd with "/etc/init.d/auditd stop" did the job*
...and sshfs was working again!
So thanks again for fighting down to the source of that bug!
Regards,
Herr Irrtum
PS: Sidenote: I still have selinux disabled.
PS2: I am not sure if it is a good idea to disable auditd completely, as
I am absolutely confused about what it's good for anyway (as security
logging does not seem to be the only purpose... but maybe I am wrong
again here). So don't use this as a general workaround as long as you do
not know what you are doing!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/46
------------------------------------------------------------------------
On 2009-09-01T15:10:34+00:00 John wrote:
I removed ALL the rules from /etc/audit/audit.rules and things started
working again, even with auditd running.
I restored them one at a time and restarting auditd. I discovered that
restoring ANY rule would cause the bug.
I did some research and discovered that these rules are related to
SELinux. In a recent upgrade from FC9 to FC11, I changed the SELinux
status in /etc/selinux/config from Permissive to Disabled. When I
changed it back and rebooted (and sat through the relabeling of my
entire filesystem), voila, everything is back to normal. I have restored
all the audit rules and restarted auditd, with no trouble.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/47
------------------------------------------------------------------------
On 2009-09-04T03:26:19+00:00 Nathaniel wrote:
Just some FYI. I do not have selinux or audit installed at all and I
have this problem. For me, the priority on this ticket is high as it is
breaking my backups (they hang every night when trying to lstat .gvfs).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/48
------------------------------------------------------------------------
On 2009-09-04T05:52:38+00:00 Dimitris wrote:
Same here, selinux is disabled and audit is not installed and I'm also
having this problem.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/49
------------------------------------------------------------------------
On 2009-09-04T16:46:56+00:00 John wrote:
Yes, I clearly spoke too soon. The problem went away temporarily, but
then returned with a vengeance (I actually tried to USE gvfs-fuse). I
removed gvfs-fuse (and totem) and the problem went away, though the bug
remains.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/50
------------------------------------------------------------------------
On 2009-09-04T16:47:29+00:00 John wrote:
Yes, I clearly spoke too soon. The problem went away temporarily, but
then returned with a vengeance (I actually tried to USE gvfs-fuse). I
removed gvfs-fuse (and totem) and the problem went away, though the bug
remains.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/51
------------------------------------------------------------------------
On 2009-09-12T09:57:43+00:00 John wrote:
over at <a href=https://bugzilla.redhat.com/show_bug.cgi?id=503956>Bug
503956</a>, a sister to this bug, some users are reporting success by
running fsck. It didn't work for me, however.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/52
------------------------------------------------------------------------
On 2009-10-06T05:31:16+00:00 Max wrote:
I am running F11 x86_64. I do not have VirtualBox. I am not using any
fuse filesystem except the auto-mounted /home/mkanat/.gvfs (which I'm
not *using*, it's just *there*). I have no custom audit rules. SELinux
is in permissve mode.
After logging out in GNOME, I 100% of the time could not log back in
again unless I rebooted or did a "kill -9" on the hung gvfs*/*mount
processes.
I did:
restorecon -Rv /home/mkanat
And now I can consistently log out and log in again without a hang.
One odd thing is that it actually told me that it couldn't correct the
/home/mkanat/.gvfs file's context, but it seems to be OK now anyway
(system_u:object_r:fusefs_t:s0). I unfortunately did not check what its
context was before the restorecon.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/53
------------------------------------------------------------------------
On 2009-10-14T15:05:24+00:00 Tomáš wrote:
*** Bug 528970 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/54
------------------------------------------------------------------------
On 2009-11-10T12:13:38+00:00 Joshua wrote:
This is a bit more information based on another user's struggles getting
fuse back. The system is F11 x86_64, 2.6.30.9-96.fc11.x86_64.
Punch line: service stop auditd;fuseiso <.iso> <dir>; service start auditd
... and I can accomplish what is needed to use fuse modules.
The server had been running since ... F9(?) with SELinux disabled. Note
that restorecon (as in comment 53) returned immediately while SELinux is
disabled. I changed /etc/sysconfig/selinux to SELINUX=permissive,
rebooted, and relabeled. Note that disabling auditd did not prevent the
hang until after the relabel and SELinux was running in permissive mode.
This is similar to comment 47, except the default auditd rules do show
this bug.
Note that this bug occured with any fuse filesystem (including the demo
'hello' one available at the sourceforge site for the project.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/55
------------------------------------------------------------------------
On 2009-11-10T14:34:15+00:00 Josef wrote:
Will somebody who doesn't have audit installed and is still seeing this
problem get sysrq-t when the box hangs so I can see where we're stuck.
To get sysrq-t you want to be root and do
echo 1 > /proc/sys/kerne/sysrq
echo t > /proc/sysrq-trigger
and then get /var/log/messages. If you cannot log in as root from the
console ore something like that you can just edit /etc/sysctl.conf and
set kernel.sysrq = 1 and then reboot, and then when the box hangs you
can hit alt+sysrq(printscrn)+t and then get /var/log/messages.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/56
------------------------------------------------------------------------
On 2009-11-10T14:36:21+00:00 Eric wrote:
I'm interested in the output from sysrq-t for anyone who has audit
disabled and is able to hit this issue. I think you would just need to
reproduce then
echo "7 7 7 7" > /proc/sys/kernel/printk
echo t > /proc/sysrq-trigger
Then attack /var/log/messages
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/57
------------------------------------------------------------------------
On 2009-11-11T01:17:13+00:00 Joshua wrote:
(In reply to comment #55)
> This is a bit more information based on another user's struggles getting fuse
> back. The system is F11 x86_64, 2.6.30.9-96.fc11.x86_64.
>
> Punch line: service stop auditd;fuseiso <.iso> <dir>; service start auditd
> ... and I can accomplish what is needed to use fuse modules.
>
> The server had been running since ... F9(?) with SELinux disabled. Note that
> restorecon (as in comment 53) returned immediately while SELinux is disabled.
> I changed /etc/sysconfig/selinux to SELINUX=permissive, rebooted, and
> relabeled. Note that disabling auditd did not prevent the hang until after the
> relabel and SELinux was running in permissive mode.
>
> This is similar to comment 47, except the default auditd rules do show this
> bug.
>
> Note that this bug occured with any fuse filesystem (including the demo 'hello'
> one available at the sourceforge site for the project.)
Brief Follow up. I disabled selinux (in /etc/sysconfig/selinux) and
rebooted, and am now able to use fuse after stopping auditd. I think
the only substantial change was the relabel when I had booted into
permissive?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/58
------------------------------------------------------------------------
On 2009-11-12T20:54:24+00:00 Josef wrote:
Patch posted upstream, we'll see if its acceptable
http://marc.info/?l=linux-fsdevel&m=125805866918258&w=2
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/59
------------------------------------------------------------------------
On 2009-11-16T09:54:06+00:00 Bug wrote:
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/60
------------------------------------------------------------------------
On 2009-11-17T19:04:37+00:00 Pascal wrote:
When audit is enabled (for example by readahead-collector), there is a deadlock
when gvfs-fuse-daemon launches mount (through fuse lib) to update fstab, and
mount calls readlink to canonalize the mountpoint, and audit requests the
xattrs of this directory, which is mounted so fuse asks the daemon which is currently blocked in waitpid, waiting for mount to exit.
The simple patch is (in fuse) to not wait for mount to return when updating
fstab.
This is exactly the same bug that happened with ntfs-3g in bug 486619
but was only fixed in the internal copy of fuse code.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/61
------------------------------------------------------------------------
On 2009-11-20T16:27:42+00:00 Josef wrote:
*** Bug 503956 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/62
------------------------------------------------------------------------
On 2009-11-20T16:29:56+00:00 Josef wrote:
Ok it seems that Miklos's inclination is to fix this by making mount/fusermount
not canonicalize the mountpoint so we don't run into this problem. I'll keep
this bug updated with the progress on the problem, hopefully we'll have
something workable in fedora soonish.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/63
------------------------------------------------------------------------
On 2009-11-25T10:46:07+00:00 Ville-Pekka wrote:
I'm marking this as a common bug for Fedora 12.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/64
------------------------------------------------------------------------
On 2009-12-08T02:21:14+00:00 John wrote:
Does anyone have the patch described in comment 61?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/65
------------------------------------------------------------------------
On 2010-01-23T14:23:53+00:00 Steve wrote:
bug still exists in 2.6.31.12-174.2.3.fc12. Is anyone working this? Is
there any information needed to fix it?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/66
------------------------------------------------------------------------
On 2010-01-23T16:04:47+00:00 Eric wrote:
This is not a kernel bug. It is a fuse-utils/util-linux bug. I believe
the util-linux package has been updated but the fuse-utils package has
not. I'm reassigning to fuse-utils and hopefully we can get the fix.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/67
------------------------------------------------------------------------
On 2010-01-23T16:10:35+00:00 Eric wrote:
http://kerneltrap.org/mailarchive/linux-
fsdevel/2009/11/12/6569103/thread
Explains the details. You should call mount with --no-canonicalize
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/68
------------------------------------------------------------------------
On 2010-01-25T15:07:36+00:00 Tomáš wrote:
*** Bug 533186 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/69
------------------------------------------------------------------------
On 2010-01-26T03:09:57+00:00 Adam wrote:
eric: not possible in F12 currently, as that option was only added to
util-linux-ng 2.17 (as discussed in the thread you link). Perhaps we
should port it to 2.16 for F12?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/70
------------------------------------------------------------------------
On 2010-02-12T22:18:21+00:00 Christopher wrote:
Nominating for F13Target since this is listed on F12 Common Bugs.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/71
------------------------------------------------------------------------
On 2010-02-17T10:07:14+00:00 Tomáš wrote:
*** Bug 562451 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/72
------------------------------------------------------------------------
On 2010-02-20T05:26:49+00:00 Matt wrote:
I think the relationship to F13Target is the wrong way around.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/73
------------------------------------------------------------------------
On 2010-03-01T11:57:11+00:00 Steven wrote:
Running LXDE on an up-to-date FC alpha RC4 with the following:
gvfs-obexftp-1.5.4-2.fc13.i686
gvfs-fuse-1.5.4-2.fc13.i686
gvfs-gphoto2-1.5.4-2.fc13.i686
gvfs-archive-1.5.4-2.fc13.i686
gvfs-smb-1.5.4-2.fc13.i686
gvfs-1.5.4-2.fc13.i686
kernel-2.6.33-0.52.rc8.git6.fc13.i686
util-linux-ng-2.17.1-1.fc13.i686
fuse-2.8.1-4.fc13.i686
fuse-libs-2.8.1-4.fc13.i686
Had my roxterm lock up when I entered the command: ls -al
At the time of the lockup:
~$ ps aux | grep gvfs
a 1696 0.0 0.0 7900 2048 ? S 05:19 0:00 /usr/libexec/gvfsd
a 1712 0.0 0.0 5232 1416 ? S 05:19 0:00 /usr/libexec//gvfs-fuse-daemon /home/a/.gvfs
root 1780 0.0 0.0 1996 696 ? S 05:19 0:00 fusermount -o rw,nosuid,nodev,subtype=gvfs-fuse-daemon -- /home/a/.gvfs
root 1797 0.0 0.0 4572 724 ? S 05:19 0:00 /bin/mount -i -f -t fuse.gvfs-fuse-daemon -o rw,nosuid,nodev,user=a gvfs-fuse-daemon /home/a/.gvfs
Killing job 1797 unlocked the system and the listing proceeded
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/74
------------------------------------------------------------------------
On 2010-03-10T17:07:59+00:00 Dave wrote:
I believe I've encountered this problem when using the fusecompress
package on Fedora 12. If a fusecompress mount is listed in fstab (as
auto) then the Fedora will hang during boot. If the mount is carried out
in rc.local then the system will boot but the mount will never complete.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/75
------------------------------------------------------------------------
On 2010-03-12T21:24:15+00:00 John wrote:
A workaround until someone applies the fixes...
mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
... and live without gvfs for the time being.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/76
------------------------------------------------------------------------
On 2010-03-15T09:26:12+00:00 Tomáš wrote:
(In reply to comment #76)
> A workaround until someone applies the fixes...
>
> mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
>
> ... and live without gvfs for the time being.
Please do not post such ideas here in bugzilla. I won't be dealing with bugs reporting completely broken desktop just because someone's suggestion. This is not Ubuntu forums...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/77
------------------------------------------------------------------------
On 2010-03-16T14:55:32+00:00 Steve wrote:
Any chance this is getting fixed soon? It really messes up software
development for utilities that walk the file system.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/78
------------------------------------------------------------------------
On 2010-03-16T20:51:19+00:00 Andy wrote:
(In reply to comment #77)
> (In reply to comment #76)
> > A workaround until someone applies the fixes...
> >
> > mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
> >
> > ... and live without gvfs for the time being.
> Please do not post such ideas here in bugzilla. I won't be dealing with bugs
> reporting completely broken desktop just because someone's suggestion. This is
> not Ubuntu forums...
This bug is almost a year old and effects 3 of my 4 machines daily. Is
there a work-a-round that is acceptable?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/79
------------------------------------------------------------------------
On 2010-03-17T07:40:47+00:00 John wrote:
1) The solution proposed in comment #76 is not a "workaround," it entirely disables the offending software.
2) The only known workaround is in comment #30, which is to kill -9 all fusermount processes and any related mount processes. You may also, if you wish, kill the gvfs-fuse-daemon, which will prevent a recurrence until the next reboot.
3) The only known solution is to disable or remove gvfs-fuse. The problem with disabling it by the method in comment #76 is that it will be re-enabled (and re-broken) when and if an upgrade occurs. Unfortunately, the Fedora packaging gods decided that Totem depends on gvfs-fuse (even though it doesn't), and therefore anytime you upgrade or reinstall Totem, this bug will be back if you use the comment #76 method.
4) The only "acceptable" solution, therefore, is to remove gvfs-fuse entirely (#yum remove gvfs-fuse). This will also remove Totem from your system. See comment #50. Given the choice between excluding Totem (there are many other video players around) vs. a system that hangs every time anyone using Nautilus logs in, I choose to live without Totem.
5) Removing gvfs-fuse entirely means it will not automatically upgrade if and when this bug is fixed. (The solution has been found but not yet incorporated into Fedora; see comment #68 and comment #70.) Thus, subscribe to this bug for news.
> (In reply to comment #79)
> (In reply to comment #77)
> > (In reply to comment #76)
> > > A workaround until someone applies the fixes...
> > >
> > > mv /usr/libexec/gvfsd /usr/libexec/gvfsd.hangs.see-bugzilla-493565
> > >
> > > ... and live without gvfs for the time being.
> > Please do not post such ideas here in bugzilla. I won't be dealing with bugs
> > reporting completely broken desktop just because someone's suggestion. This is
> > not Ubuntu forums...
>
> This bug is almost a year old and effects 3 of my 4 machines daily. Is there a
> work-a-round that is acceptable?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/80
------------------------------------------------------------------------
On 2010-03-17T15:33:19+00:00 Adam wrote:
"Unfortunately, the Fedora packaging gods decided that Totem depends on
gvfs-fuse (even though it doesn't), and therefore anytime you upgrade or
reinstall Totem, this bug will be back if you use the comment #76
method."
There are no 'Fedora packaging gods', just packagers. The Totem packager
is Bastien Nocera. He's not a god. I've checked. If you think the
dependency is incorrect, file a bug. He will either remove it or explain
why he considers it to be a dependency. Note that Fedora has no concept
of soft dependencies, so packagers sometimes set hard dependencies on
packages which aren't strictly _required_ for the software to function,
if they feel that most users will expect the 'optional' functionality to
be present, and would not know how to add it manually.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/81
------------------------------------------------------------------------
On 2010-03-27T18:02:27+00:00 Dmytro wrote:
This bug should block F13Target rather than depend on F13Target (since
this bug can be fixed without fixing F13Target). I do not have
permissions to fix this myself.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/82
------------------------------------------------------------------------
On 2010-03-29T18:26:31+00:00 Christopher wrote:
Fixed dependency/block relationships.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/83
------------------------------------------------------------------------
On 2010-03-29T19:58:08+00:00 Josef wrote:
This bz depends on 577947, since we need mount to have the --no-
canonicalize option. Once util-linux-ng is updated, fuse can be updated
to 2.8.3 and this problem will go away.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/84
------------------------------------------------------------------------
On 2010-03-29T20:20:06+00:00 Ville-Pekka wrote:
Are the target bugs actually used for anything these days? I think I've
seen some discussion about Fedora possibly not using target bugs at all
in the future. Should this bug rather depend on the Fedora 13 Blocker
bug?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/85
------------------------------------------------------------------------
On 2010-03-31T02:57:36+00:00 Adam wrote:
It's not a release blocking issue.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/86
------------------------------------------------------------------------
On 2010-03-31T09:08:33+00:00 John wrote:
Re comment 86, I can see that this might not block the release, but in
that case is there a status that says, if this bug isn't fixed by F13,
remove the software from the release?
Just how defective does software have to be to be pulled? Something that
verifiably prevents all logins every time it is used would seem to me to
be a problem.
Re comment 70, this makes total sense to me but it should be backported
to F11 too.
Re comment 81, thanks for the info!
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/87
------------------------------------------------------------------------
On 2010-03-31T19:32:17+00:00 Adam wrote:
"Re comment 86, I can see that this might not block the release, but in that
case is there a status that says, if this bug isn't fixed by F13, remove the
software from the release?"
No.
"Just how defective does software have to be to be pulled? Something that
verifiably prevents all logins every time it is used would seem to me to be a
problem."
I don't know if there's a definitive policy on this. You could perhaps
bring it to the attention of FESCo or the packaging committee?
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/88
------------------------------------------------------------------------
On 2010-04-12T19:17:12+00:00 Josef wrote:
Ok now that
https://bugzilla.redhat.com/show_bug.cgi?id=577947
has made it into F12, all that needs to be done is fuse needs to be
updated to 2.8.3. Once thats done this problem will go away.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/89
------------------------------------------------------------------------
On 2010-04-16T09:17:13+00:00 Tomáš wrote:
*** Bug 582878 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/90
------------------------------------------------------------------------
On 2010-04-18T17:46:01+00:00 Stas wrote:
Very annoying bug, nice to see
a progress with it.
But I am having the different
trace, in my case the lstat causes
the problem, and not readlink().
Does this make any difference?
mc S ffff88007b1ba800 0 3628 2668 0x00000080
ffff8800354a9cc8 0000000000000082 000000006d2c3a80 ffffffff81a01218
00000010354a9c38 ffffffff8112eef5 ffff8800354a9fd8 ffff8800354a9fd8
ffff88005291c9f8 000000000000f980 0000000000015740 ffff88005291c9f8
Call Trace:
[<ffffffff8112eef5>] ? dput+0x45/0x131
[<ffffffffa0443c77>] fuse_get_req+0xae/0x13f [fuse]
[<ffffffff810748ab>] ? autoremove_wake_function+0x0/0x39
[<ffffffff811ec9fc>] ? inode_has_perm+0x7a/0x90
[<ffffffffa0444596>] fuse_do_getattr+0x3c/0x24b [fuse]
[<ffffffff8110b643>] ? virt_to_head_page+0xe/0x2f
[<ffffffff811ece51>] ? dentry_has_perm+0x5a/0x70
[<ffffffffa044606b>] fuse_update_attributes+0x30/0x5f [fuse]
[<ffffffffa04460e3>] fuse_getattr+0x49/0x4e [fuse]
[<ffffffff8111f985>] vfs_getattr+0x48/0x66
[<ffffffff8111f9ee>] vfs_fstatat+0x4b/0x62
[<ffffffff8111fa60>] vfs_lstat+0x1e/0x20
[<ffffffff8111fa81>] sys_newlstat+0x1f/0x3d
[<ffffffff81125373>] ? path_put+0x22/0x26
[<ffffffff81011d32>] system_call_fastpath+0x16/0x1b
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/91
------------------------------------------------------------------------
On 2010-04-28T03:09:51+00:00 Krishna wrote:
Here is what I did to (temporarily?) fix the problem:
yum remove gvfs-fuse totem-nautilus totem gvfs-smb bluez nautilus gvfs-gphoto2 gvfs-archive gvfs gvfs-obexftp gnome-bluetooth pulseaudio-module-bluetooth
rm -rf ~/.gvfs
reboot
yum install gvfs-fuse totem-nautilus totem gvfs-smb bluez nautilus gvfs-gphoto2 gvfs-archive gvfs gvfs-obexftp gnome-bluetooth pulseaudio-module-bluetooth
reboot
Obviously, this is a quick fix until the problem is really solved --
hopefully in F13.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/92
------------------------------------------------------------------------
On 2010-04-28T03:22:49+00:00 Krishna wrote:
I forgot to add what I current have on my system--
totem-2.28.5-1.fc12.x86_64
pulseaudio-module-bluetooth-0.9.21-5.fc12.x86_64
nautilus-extensions-2.28.4-2.fc12.x86_64
nautilus-sendto-2.28.2-2.fc12.x86_64
gvfs-archive-1.4.3-7.fc12.x86_64
bluez-cups-4.58-1.fc12.x86_64
gnome-bluetooth-libs-2.28.6-2.fc12.x86_64
gvfs-smb-1.4.3-7.fc12.x86_64
totem-nautilus-2.28.5-1.fc12.x86_64
bluez-4.58-1.fc12.x86_64
brasero-nautilus-2.28.3-1.fc12.x86_64
bluez-libs-4.58-1.fc12.x86_64
gvfs-1.4.3-7.fc12.x86_64
gvfs-obexftp-1.4.3-7.fc12.x86_64
nautilus-2.28.4-2.fc12.x86_64
totem-pl-parser-2.28.2-1.fc12.x86_64
gvfs-gphoto2-1.4.3-7.fc12.x86_64
totem-mozplugin-2.28.5-1.fc12.x86_64
gvfs-fuse-1.4.3-7.fc12.x86_64
gnome-bluetooth-2.28.6-2.fc12.x86_64
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/93
------------------------------------------------------------------------
On 2010-04-28T09:23:28+00:00 Tomáš wrote:
(In reply to comment #92)
...
> rm -rf ~/.gvfs
...
This will reliably delete all data from your active mounts (FTP, SFTP,
SMB etc.).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/94
------------------------------------------------------------------------
On 2010-05-22T16:11:17+00:00 Sébastien wrote:
"ls -la" in the home directory also hangs on F13.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/95
------------------------------------------------------------------------
On 2010-05-29T23:47:42+00:00 Brian wrote:
I can also confirm this happens on F13.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/96
------------------------------------------------------------------------
On 2010-06-03T21:49:33+00:00 Mehmet wrote:
Confirming bug in F13 . The same after all updates .
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/97
------------------------------------------------------------------------
On 2010-06-04T13:48:53+00:00 Harald wrote:
ARGH - This are really the audit-rules
After comment out them fuse works again
So the following report from me is the same and has nothing to do with umask
https://bugzilla.redhat.com/show_bug.cgi?id=585302
______________________________________
[root at srv-rhsoft:~]$ cat /etc/audit/audit.rules
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320
# Feel free to add below this line. See auditctl man page
# -w /etc/passwd -p wa -k password-file
# -w /etc/group -p wa -k password-file
# -w /etc/shadow -p wa -k password-file
# -w /etc/gshadow -p wa -k password-file
# -w /root/.ssh/authorized_keys2 -p wa -k ssh-keyfile
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/98
------------------------------------------------------------------------
On 2010-06-04T15:05:58+00:00 David wrote:
I'm not running auditd and I still get hangs on 'ls -al ~', so it's
doubtful that audit's involved.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/99
------------------------------------------------------------------------
On 2010-06-04T19:23:47+00:00 Adam wrote:
*** Bug 585302 has been marked as a duplicate of this bug. ***
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/100
------------------------------------------------------------------------
On 2010-06-07T11:02:16+00:00 Mehmet wrote:
(In reply to comment #99)
> I'm not running auditd and I still get hangs on 'ls -al ~', so it's doubtful
> that audit's involved.
I can confirm this too .
I disabled audit service, removed gvfs.fuse via yum but still having
this problem.
After repeating these steps in F12 I wrote above, there was no problem .
But in F13 it does not help. I can view home folder a couple of times after reboot then it hangs after 5~6 minutes uptime.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/101
------------------------------------------------------------------------
On 2010-06-07T11:16:04+00:00 Eric wrote:
In response to comment #101, this must be some new problem. Can you
give the output of ps -ef | grep mount during the hang? Can you also
run
echo t > /proc/sysrq-trigger
and then attach the resulting output in /var/log/messages?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/102
------------------------------------------------------------------------
On 2010-06-07T13:21:22+00:00 Josef wrote:
Fuse still needs to be updated to take advantage of the new --no-
canonicalize option in util-linux. Until fuse is updated to 2.8.3 or
later this problem will continue to happen. I'm not the maintainer of
fuse for Fedora so I can't do it, whoever owns the package is going to
have to do it.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/103
------------------------------------------------------------------------
On 2010-06-08T05:07:33+00:00 Peter wrote:
I'll update fuse shortly.
Folks, next time, please, file tickets against fuse and not against
fuse-utils.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/104
------------------------------------------------------------------------
On 2010-06-08T05:19:51+00:00 Fedora wrote:
fuse-2.8.4-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc12
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/105
------------------------------------------------------------------------
On 2010-06-08T05:19:57+00:00 Fedora wrote:
fuse-2.8.4-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc11
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/106
------------------------------------------------------------------------
On 2010-06-08T05:20:03+00:00 Fedora wrote:
fuse-2.8.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/fuse-2.8.4-1.fc13
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/107
------------------------------------------------------------------------
On 2010-06-09T08:29:45+00:00 Peter wrote:
Folks, please install fuse from updates-testing and leave a comment in
Bodhi about whether this build fixes this issue or not.
I, personally, can't say anything about this issue because I don't use
gfvs at all (although it does installed on my machines as a dependency)
- at least this build doesn't break anything.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/108
------------------------------------------------------------------------
On 2010-06-09T21:48:24+00:00 Mehmet wrote:
The update above works. Problem solved.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/109
------------------------------------------------------------------------
On 2010-06-10T19:12:57+00:00 Fedora wrote:
fuse-2.8.4-1.fc13 has been pushed to the Fedora 13 stable repository.
If problems still persist, please make note of it in this bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/110
------------------------------------------------------------------------
On 2010-06-14T17:11:16+00:00 Fedora wrote:
fuse-2.8.4-1.fc11 has been pushed to the Fedora 11 stable repository.
If problems still persist, please make note of it in this bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/111
------------------------------------------------------------------------
On 2010-06-14T17:15:30+00:00 Fedora wrote:
fuse-2.8.4-1.fc12 has been pushed to the Fedora 12 stable repository.
If problems still persist, please make note of it in this bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/112
------------------------------------------------------------------------
On 2010-06-17T00:22:39+00:00 Dave wrote:
Tested on fedora 12 with fuse-2.8.4-1.fc12. fusecompress still hangs the
system on boot if auto mounted in fstab.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/113
------------------------------------------------------------------------
On 2010-06-17T08:00:17+00:00 John wrote:
(In reply to comment #111)
> fuse-2.8.4-1.fc11 has been pushed to the Fedora 11 stable repository. If
> problems still persist, please make note of it in this bug report.
Still hangs on Fedora 11, which is using util-linux-ng version
2.14.2-11.
If I understand comment #68 and comment #70 correctly, the solution
requires a "--no-canonicalize" option for mount. I have no idea where in
the guts of the system this would take place, but I also understand from
the same comment that util-linux-ng needs to be at least version 2.17
for this to work.
Since util-linux-ng goes SO deep into the system, I am wary of any
experimenting. I assume, therefore, that I will need to upgrade at least
to FC12 for this to work, but I also see from comment #70 that it hasn't
been ported there, either. In fact, the latest I can see for FC12 is
2.16.2-9, so perhaps this will work only with FC13?
In any case, this part of the solution seems to rest with the maintainer
of util-linux-ng, who I think is Karel Zak, not with Peter Lemenkov.
I see that Peter Lemenkov asked for comments to be left in Bodhi, which
will be my next effort :)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/114
------------------------------------------------------------------------
On 2010-06-17T08:06:35+00:00 John wrote:
(In reply to comment #108)
> Folks, please install fuse from updates-testing and leave a comment in Bodhi
> about whether this build fixes this issue or not.
>
> I, personally, can't say anything about this issue because I don't use gfvs at
> all (although it does installed on my machines as a dependency) - at least this
> build doesn't break anything.
Though this fix was pushed to FC11, it doesn't solve the problem, as
util-linux-ng was never upgraded on FC11. (See comment #70)
>From comment #89, I see that util-linux-ng was upgraded on FC12, so
perhaps the solution is to move to FC12, but it's kinda pointless to
upgrade fuse on FC11 when its companion util-linux-ng problem remains.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/115
------------------------------------------------------------------------
On 2010-06-17T08:31:47+00:00 Peter wrote:
> (In reply to comment #111)
> Still hangs on Fedora 11, which is using util-linux-ng version
2.14.2-11.
I was not aware of the status of util-linux-ng in F-11. I'm afraid that
it won't be upgraded at all considering that F-11 will be EOLed very
soon.
Anyway, I believe that I did my part of job.
> Since util-linux-ng goes SO deep into the system, I am wary of any
> experimenting. I assume, therefore, that I will need to upgrade at least to
> FC12 for this to work, but I also see from comment #70 that it hasn't been
> ported there, either. In fact, the latest I can see for FC12 is 2.16.2-9, so
> perhaps this will work only with FC13?
Yes, I'm afraid so - in order to fix this issue util-linux-ng should be
upgraded in F-12 too.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/116
------------------------------------------------------------------------
On 2010-06-18T15:01:02+00:00 Peter wrote:
Ok, since now fuse-related part of work was finished, I'm switching this
ticket to util-linux-ng, which should be updated in F-12 in order to
completely fix this issue.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/117
------------------------------------------------------------------------
On 2010-06-21T07:50:11+00:00 Karel wrote:
Hmm..., bug 577947, I see:
* Mon Apr 12 2010 Karel Zak <kzak at redhat.com> 2.16.2-9
- fix #577947 - need --no-canonicalize option for mount
bodhi - 2010-05-07 17:25:08
This update has been pushed to stable
https://admin.fedoraproject.org/updates/util-linux-
ng-2.16.2-9.fc12?_csrf_token=76c49b8f4800907c7c5dc3f082bf3e5a4a9262d9
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/118
------------------------------------------------------------------------
On 2010-07-22T14:37:22+00:00 Henrique wrote:
Not sure if this is related but it was the bug that came out on a google
search and it seems to have similar origin, i.e. fuse.
Question, are fuse mounts supposed to survive reboots?
They did for me once. X hang on my x86_64 nightly updated F13 when
trying to display a quite large image from wikipedia. Mouse worked, not
keyboard. Ssh'ed from another machine, killed a couple of things to see
if I could recover but eventually needed to shutdown -r.
I have pam_ssh installed and modify the pam scripts so I log in with my
ssh passphrase. I log on with gdm but run don't run gnome,
xinit/xsession/fvwm instead.
When I logged on again I noticed I couldn't ssh to any of the places I
usually do, without entering my passphrase, like ssh-agent wasn't
proper. Logged off and on a couple of times and no go. Eventually I
found that I still had another system fuse mounted, just like it was
before the machine was rebooted.
Unmounted that fs, logged off then on, and things are normal again.
Strange and scary. Not sure I can replicate it again.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/119
------------------------------------------------------------------------
On 2010-09-02T00:35:35+00:00 Jon wrote:
The underlying mount command that is hanging does not hang for users
that belong to the 'video' system group.
I took users out of that group which they get put into by default, and
the problem happened consistently. Once I put them back in and killed
the hung mount processes, the problem no longer happens.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/120
------------------------------------------------------------------------
On 2012-04-16T11:18:43+00:00 Richard wrote:
For those following this, I think this bug has reappeared
in Fedora 17. The symptoms are extremely similar (even
the FUSE "hello" example hangs), and disabling selinux fixes
it (but *not* just setting selinux to permissive).
https://bugzilla.redhat.com/show_bug.cgi?id=812798
Reply at:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/comments/146
** Changed in: fuse (Fedora)
Status: Unknown => Fix Released
** Changed in: fuse (Fedora)
Importance: Unknown => High
** Bug watch added: Red Hat Bugzilla #503956
https://bugzilla.redhat.com/show_bug.cgi?id=503956
** Bug watch added: Red Hat Bugzilla #577947
https://bugzilla.redhat.com/show_bug.cgi?id=577947
** Bug watch added: Red Hat Bugzilla #585302
https://bugzilla.redhat.com/show_bug.cgi?id=585302
** Bug watch added: Red Hat Bugzilla #812798
https://bugzilla.redhat.com/show_bug.cgi?id=812798
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to fuse in Ubuntu.
https://bugs.launchpad.net/bugs/634554
Title:
fuse mounts hang on xattr retrieval with auditd
Status in fuse package in Ubuntu:
Fix Released
Status in fuse source package in Lucid:
Fix Released
Status in fuse source package in Maverick:
Fix Released
Status in fuse package in Debian:
Fix Released
Status in fuse package in Fedora:
Fix Released
Bug description:
Impact: If audit is enabled in the kernel, mounting fuse filesystems hangs.
Development branch (and maverick): Addressed by upgrade to upstream fuse >= 2.8.3.
Patch: https://code.launchpad.net/~cjwatson/ubuntu/lucid/fuse/audit-hang (backported from upstream - it's not particularly short, but there were three intertwined fixes and this was the best I could do)
TEST CASE: Install auditd and configure a rule, then try to mount a fuse filesystem.
Regression potential: I'd recommend generally playing around with fuse and making sure it still works. Running the udisks test suite might be a good idea.
Original report follows:
Binary package hint: libfuse2
I'm being struck by the symptoms reported in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=493565
Namely, when auditd has any rules configured, I can't mount any fuse
file-systems. Comment 61 seems to have a pretty solid description of
what's happening underneath and the solution appears to be upgrading
to a libfuse > 2.8.3. Only 2.8.1
(http://packages.ubuntu.com/lucid/libfuse2) appears to be available
currently for lucid.
Cheers,
peter
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/634554/+subscriptions
More information about the foundations-bugs
mailing list