Comment 13 for bug 1558967

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-04-13 12:51 EDT-------
(In reply to comment #43)
> Hm, but there is this comment earlier on "I verified that Hendriks suggested
> fix (using a pipe for synchronization) does fix the problem for cmsfs-fuse."
> -> is there code to do that, or is that the hack that is in place in Wave
> right now?

The "pipe synchronization" would be an example fix for the bug in fuse, as explained by Hendrik at the beginning of this bugzilla. The race in fuse_daemonize() leads to the issues that we see in Wave using cmsfs-fuse, but there is no bug neither in Wave nor in cmsfs-fuse, only in libfuse itself.

As noted earlier, the race in libfuse that leads to the "Transport endpoint is not connected" error can also be reproduced w/o Wave or cmsfs-fuse, by using "setsid -c" and sshfs (and probably any other fuse fs):

root@s3545003:~# setsid -c sshfs geraldsc@tuxmaker: sshfs/
root@s3545003:~# ls sshfs
ls: cannot access 'sshfs': Transport endpoint is not connected

When applying the suggested "pipe synchronization" fix from Hendrik to libfuse, it solves the issue for Wave and cmsfs-fuse. For sshfs, it also fixes the "Transport endpoint is not connected" error, but unfortunately sshfs itself also does some forking on its own, which also seems to be broken, which is why using sshfs as in the above example still doesn't work as expected (but at least now w/o the "Transport endpoint" error).

Unfortunately we have no clearance to submit patches directly to libfuse, so there is only the "general hint" about using a pipe for synchronization between parent and child inside fuse_daemonize(). I have just verified that such a patch for libfuse would fix the issue, and now we hope that someone could implement and integrate it into libfuse (and then into Ubuntu).