Go-ipfs: sharness test failure

[whyrusleeping]

set my desktop to continually run tests on master over and over again, came back to find it had failed here.

./t0030-mount.sh
ok 1 - ipfs init succeeds
ok 2 - prepare config -- mounting and bootstrap rm
ok 3 - 'ipfs daemon' succeeds
ok 4 - 'ipfs daemon' is ready
ok 5 - 'ipfs daemon' output includes Gateway address
ok 6 - 'ipfs mount' fails when there is no mount dir
ok 7 - 'ipfs mount' output looks good
ok 8 - 'ipfs mount' succeeds
ok 9 - 'ipfs mount' output looks good
ok 10 - mount directories cannot be removed while active
ok 11 - 'ipfs daemon' is still running
ok 12 - 'ipfs daemon' can be killed
not ok 13 - mount directories can be removed after shutdown
#   
#       rmdir ipfs ipns
#   
# failed 1 among 13 test(s)
1..13

[jbenet]

Yeah i sometimes see this-- any ideas? fuse stuck?

[chriscool]

Yeah I also sometimes see this.
When this happens /dev/fuse is still mounted, though the daemon should have unmounted it before dying.

[whyrusleeping]

I havent seen this for a while, but its likely thats because we don't run fuse tests hardly ever. I'll leave this open for now.

[jbenet]

We should be running those always. Travis CI has supported fuse for a long
time now.

Cc @chriscool thoughts?
On Tue, Aug 23, 2016 at 17:33 Jeromy Johnson [email protected]
wrote:

I havent seen this for a while, but its likely thats because we don't run
fuse tests hardly ever. I'll leave this open for now.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ipfs/go-ipfs/issues/1243#issuecomment-241886898, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcocFsiG6I1PlsrTXFMBp3k7dy4Dsyks5qi2cngaJpZM4Efcoa
.

[chriscool]

Yeah, we should have been doing that and we probably should have merged at least some parts of this PR that fixed fuse problems:

https://github.com/ipfs/go-ipfs/pull/2324

[wigy-opensource-developer]

This problem still exists. FUSE related tests are not automated. They do not seem to be run by anyone manually either.

When I run the sharness locally on Linux, the actual issue seems to be that ipfs mount cannot succeed without ipfs name publish /ipfs/QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn that cannot succeed without bootstrapping other peers ("Error: failed to find any peer in table" comes from IpfsDHT.GetValues)

Possible options I see:

• IPFS needs to support publishing during a network partition
• the ipfs mount should not rely on having any IPNS records in the datastore
• all sharness tests need to have enough nodes running to support the read quorum needed for the name publish

[Kubuxu]

FUSE currently is in very bad state it has bigger problems than sharness not running, for example our unit tests for FUSE are hanging in the kernel. After 0.4.5 is released we will try updating the fuse lib to check if it fixes any problems, see: https://github.com/ipfs/go-ipfs/pull/3414 and we can proceed from there.

[whyrusleeping]

We've updated our fuse libs. Can someone re-verify that this is an issue?

[magik6k]

Ran this in a loop for 10+ mins without a single fail, I'll call this fixed.