fuse-devel

[fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Christoph L. <la...@we...>]

Dear fuse developers,

I hope I'll be able to report a bug this way.  I'm not sufficiently 
knowledgeable to really get involved into the _development_ of fuse, so 
I don't want to _subscribe_ to this list and hope you'll accept this 
post.  (Maybe the project homepage should provide clearer instructions 
on how to report bugs.)

So there may have been a regression in fuse 2.9.1 compared to the 2.8 
series.  I heavily rely on a fuse-mounted ntfs3g file system, using 
ntfs3g-2012.1.15.  Until recently this has worked without any problems, 
but as soon as I upgraded to fuse 2.9.1 the ntfs3g process frequently 
died.  The symptom has been described at 
https://bbs.archlinux.org/viewtopic.php?id=146157 (where the reason was 
probably a different one).  Basically, the ntfs3g process dies, while 
many other processes still have files opened on the fuse-mounted ntfs3g 
volume, resulting in error messages such as

cannot access /mnt/data: Transport endpoint is not connected

Therefore umount doesn't work.  umount -l of course works, but executing 
mount once more still leaves me with the error.  So I only found 
rebooting an effective solution.

OK, so this is possibly a bug with ntfs3g-2012.1.15 no longer being 
compatible with fuse 2.9, which might require package maintainers to fix 
their dependencies.  Or it is a regression in fuse.  So for now I will 
only report the bug here.  But if you ask me to file it with ntfs3g or 
with my distribution (Gentoo), I will happily do so.

I have now downgraded to fuse 2.8.6 and hope that that temporarily fixes 
the problem.

Cheers, and thanks,

Christoph

-- 
Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701

Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Jean-Pierre A. <jea...@wa...>]

Hi Christoph,

Christoph LANGE wrote:
> Dear fuse developers,
>
> I hope I'll be able to report a bug this way.  I'm not sufficiently
> knowledgeable to really get involved into the _development_ of fuse, so
> I don't want to _subscribe_ to this list and hope you'll accept this
> post.  (Maybe the project homepage should provide clearer instructions
> on how to report bugs.)
>
> So there may have been a regression in fuse 2.9.1 compared to the 2.8
> series.  I heavily rely on a fuse-mounted ntfs3g file system, using
> ntfs3g-2012.1.15.  Until recently this has worked without any problems,
> but as soon as I upgraded to fuse 2.9.1 the ntfs3g process frequently
> died.  The symptom has been described at
> https://bbs.archlinux.org/viewtopic.php?id=146157 (where the reason was
> probably a different one).  Basically, the ntfs3g process dies, while
> many other processes still have files opened on the fuse-mounted ntfs3g
> volume, resulting in error messages such as
>
> cannot access /mnt/data: Transport endpoint is not connected
>    

This means the fuse process has hung.

You did not give details, but a frequent cause for
this on fuse 2.9.0 and 2.9.1 is covered by the fix described
in 
http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1061a0a2d90148bd2e7f32e1e694399db2dbe087

> Therefore umount doesn't work.  umount -l of course works, but executing
> mount once more still leaves me with the error.  So I only found
> rebooting an effective solution.
>
> OK, so this is possibly a bug with ntfs3g-2012.1.15 no longer being
> compatible with fuse 2.9, which might require package maintainers to fix
> their dependencies.  Or it is a regression in fuse.  So for now I will
> only report the bug here.  But if you ask me to file it with ntfs3g or
> with my distribution (Gentoo), I will happily do so.
>
> I have now downgraded to fuse 2.8.6 and hope that that temporarily fixes
> the problem.
>    

Or upgrade to the latest fuse version with all the bug fixes.

Regards

Jean-Pierre

Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Christoph L. <la...@we...>]

Hi Jean-Pierre,

thanks for your reply!

2012-10-19 12:32 Jean-Pierre André:
> You did not give details,

How would I be able to obtain such details in future?  Is there a 
generic logging facility for fuse filesystems?  Or do I have to rely on 
whatever the specific fuse filesystem provides?  (I see from "man 
ntfs-3g" that this filesystem has the options "debug" and "no_detach", 
which I should probably have used.)

> but a frequent cause for
> this on fuse 2.9.0 and 2.9.1 is covered by the fix described
> in
> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1061a0a2d90148bd2e7f32e1e694399db2dbe087

Thanks for letting me know!

> Or upgrade to the latest fuse version with all the bug fixes.

With regard to this I have reported the problem back to Gentoo, my Linux 
distributor (where fuse-2.9.1-r1 is the latest version so far); see 
https://bugs.gentoo.org/show_bug.cgi?id=437568#c11

Cheers,

Christoph

-- 
Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701

Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Jean-Pierre A. <jea...@wa...>]

Hi again,

Christoph LANGE wrote:
> Hi Jean-Pierre,
>
> thanks for your reply!
>
> 2012-10-19 12:32 Jean-Pierre André:
>> You did not give details,
>
> How would I be able to obtain such details in future?  Is there a 
> generic logging facility for fuse filesystems?  Or do I have to rely 
> on whatever the specific fuse filesystem provides?  (I see from "man 
> ntfs-3g" that this filesystem has the options "debug" and "no_detach", 
> which I should probably have used.)

I just meant that I did not get a clue to confirm the
fix I mentioned was related to the issue you reported.

In most situation, the initial clue is logged into the
system log (whose location depends on the distribution),
and ntfs-3g and fuse try to log unusual conditions which
are met. The fix I suggested is related to having
"fuse internal error: node NNN not found" in the system
log file. Do you have this or something else logged ?

Using the debug option may be useful in complex
situations when there is no other clue.

>> but a frequent cause for
>> this on fuse 2.9.0 and 2.9.1 is covered by the fix described
>> in
>> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1061a0a2d90148bd2e7f32e1e694399db2dbe087 
>>
>
> Thanks for letting me know!
>
>> Or upgrade to the latest fuse version with all the bug fixes.
>
> With regard to this I have reported the problem back to Gentoo, my 
> Linux distributor (where fuse-2.9.1-r1 is the latest version so far); 
> see https://bugs.gentoo.org/show_bug.cgi?id=437568#c11

The "-r1" suffix may mean some fix has been applied to
the base fuse-2.9.1, so I cannot really tell whether the one
I mentioned has been applied. Get the corresponding
source code, and check.

Regards

Jean-Pierre

Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Christoph L. <la...@we...>]

2012-10-19 13:50 Jean-Pierre André:
> In most situation, the initial clue is logged into the
> system log (whose location depends on the distribution),

OK, thanks for your hints – I inspected my system log (which is created 
by syslog-ng without any custom configuration) and couldn't find any 
related information.  I inspected /var/log/messages; on my system there 
is no log file that would contain further information more specific to fuse.

> and ntfs-3g and fuse try to log unusual conditions which
> are met.

So all that I found about fuse is the startup message "fuse init (API 
version ...)" (with version either 7.18 or 7.20).

> The fix I suggested is related to having
> "fuse internal error: node NNN not found" in the system
> log file. Do you have this or something else logged ?

No, I don't – so it is probably a different bug that I experienced.

There was also some log output from the ntfs-3g process, which, AFAICT, 
was logged whenever I tried to umount the partition after the ntfs-3g 
process had died:

Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Version 2012.1.15 external 
FUSE 29
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mounted /dev/sda4 
(Read-Write, label "Data (Windows/Linux)", NTFS 3.1)
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Cmdline options: 
rw,uid=1000,gid=100,windows_names
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mount options: 
rw,allow_other,nonempty,relatime,fsname=/dev/sda4,blkdev,blksize=4096
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: User mapping built, Posix 
ACLs in use, configuration type 7
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Unmounting /dev/sda4 (Data 
(Windows/Linux))

I didn't see any further ntfs-3g output.

>> With regard to this I have reported the problem back to Gentoo, my
>> Linux distributor (where fuse-2.9.1-r1 is the latest version so far);
>> see https://bugs.gentoo.org/show_bug.cgi?id=437568#c11
>
> The "-r1" suffix may mean some fix has been applied to
> the base fuse-2.9.1, so I cannot really tell whether the one
> I mentioned has been applied. Get the corresponding
> source code, and check.

In this case it probably doesn't mean that any patch has been applied. 
The following diff between 2.9.1 and 2.9.1-r1 shows some minor changes, 
IIUC related to distribution-specific tools and path lookups:

--- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< ---
$ diff /usr/portage/sys-fs/fuse/fuse-2.9.1{,-r1}.ebuild
3c3
< # $Header: /var/cvsroot/gentoo-x86/sys-fs/fuse/fuse-2.9.1.ebuild,v 1.1 
2012/08/01 22:31:55 radhermit Exp $
---
> # $Header: /var/cvsroot/gentoo-x86/sys-fs/fuse/fuse-2.9.1-r1.ebuild,v 1.5 2012/10/17 03:41:17 phajdan.jr Exp $
6c6
< inherit libtool linux-info
---
> inherit eutils libtool linux-info toolchain-funcs
15c15
< KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 
~x86-fbsd ~amd64-linux ~x86-linux"
---
> KEYWORDS="~alpha amd64 ~arm ~hppa ~ia64 ppc ppc64 ~sparc x86 ~x86-fbsd ~amd64-linux ~x86-linux"
18a19,20
> RDEPEND=""
> DEPEND="virtual/pkgconfig"
37a40,42
>       local UDEV_PATH=/lib/udev
>       has_version sys-fs/udev && UDEV_PATH="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
>
41c46
<               UDEV_RULES_PATH="${EPREFIX}/lib/udev/rules.d" \
---
>               UDEV_RULES_PATH="${EPREFIX}/${UDEV_PATH}/rules.d" \
65c70
<       find "${ED}" -name "*.la" -delete
---
>       prune_libtool_files
--- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< ---

In particular, the source URL is the same, and no patches are applied.

Cheers,

Christoph

-- 
Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701

Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Jean-Pierre A. <jea...@wa...>]

Hi again,

Christoph LANGE wrote:
> 2012-10-19 13:50 Jean-Pierre André:
>> In most situation, the initial clue is logged into the
>> system log (whose location depends on the distribution),
>
> OK, thanks for your hints – I inspected my system log (which is 
> created by syslog-ng without any custom configuration) and couldn't 
> find any related information.  I inspected /var/log/messages; on my 
> system there is no log file that would contain further information 
> more specific to fuse.
>
>> and ntfs-3g and fuse try to log unusual conditions which
>> are met.
>
> So all that I found about fuse is the startup message "fuse init (API 
> version ...)" (with version either 7.18 or 7.20).
>
>> The fix I suggested is related to having
>> "fuse internal error: node NNN not found" in the system
>> log file. Do you have this or something else logged ?
>
> No, I don't – so it is probably a different bug that I experienced.
>
> There was also some log output from the ntfs-3g process, which, 
> AFAICT, was logged whenever I tried to umount the partition after the 
> ntfs-3g process had died:
>
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Version 2012.1.15 external 
> FUSE 29
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mounted /dev/sda4 
> (Read-Write, label "Data (Windows/Linux)", NTFS 3.1)
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Cmdline options: 
> rw,uid=1000,gid=100,windows_names
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mount options: 
> rw,allow_other,nonempty,relatime,fsname=/dev/sda4,blkdev,blksize=4096
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: User mapping built, Posix 
> ACLs in use, configuration type 7
> Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Unmounting /dev/sda4 (Data 
> (Windows/Linux))
>
> I didn't see any further ntfs-3g output.
>
>>> With regard to this I have reported the problem back to Gentoo, my
>>> Linux distributor (where fuse-2.9.1-r1 is the latest version so far);
>>> see https://bugs.gentoo.org/show_bug.cgi?id=437568#c11
>>
>> The "-r1" suffix may mean some fix has been applied to
>> the base fuse-2.9.1, so I cannot really tell whether the one
>> I mentioned has been applied. Get the corresponding
>> source code, and check.
>
> In this case it probably doesn't mean that any patch has been applied. 
> The following diff between 2.9.1 and 2.9.1-r1 shows some minor 
> changes, IIUC related to distribution-specific tools and path lookups:
>
> In particular, the source URL is the same, and no patches are applied.

If the fix I mentioned is not applied, please apply it
and retry. This will at least rule out a possible cause,
though the logging item I expected is not found (the
ntfs-3g logging is standard : no bad condition detected).

Does the crash occur randomly ?

Regards

Jean-Pierre