Go-ipfs: Accessing resources via /ipns mount hangs for names that otherwise resolve properly

[dmzimmerman]

I've created a few IPFS nodes - first in isolation as a "private" cluster knowing only about others in the cluster, and later using the standard set of bootstrap nodes - and had difficulties using the /ipns FUSE mount point.

Assume that two of my nodes had node IDs ABCDEF and FEDCBA. What I expected was that on node ABCDEF I could create a few files under /ipns/local; then, on node FEDCBA, I could run ls /ipns/ABCDEF and see the files I'd created (after a suitable propagation time). Instead, what actually happens is that ls /ipns/ABCDEF hangs forever on node FEDCBA. However, if I run ipfs resolve /ipns/ABCDEF and then ls (the result of ipfs resolve /ipns/ABCDEF) on node FEDCBA, it works fine.

It seems to me like either both of those ways of accessing the resources should work, or neither of them should, in any given instance.

Configuration information: ipfs 0.4.2, Fedora 23, go1.5.4 linux/amd64 (I've also tried it with go1.6.2 darwin/amd64 on a Mac OS X machine, and gotten the same result)

[whyrusleeping]

We've recently upgraded our fuse dependency. Do you mind trying out lastest master? (post 0.4.6)

[timthelion]

I can confirm this post 0.4.6:

timothy@yoga ~> ipfs version --all go-ipfs version: 0.4.8- Repo version: 5 System version: amd64/linux Golang version: go1.8 timothy@yoga ~> uname -a Linux yoga 4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux

````
timothy@yoga ~> cat ~/ipfs/QmQvtfcQ4DyRTeD54RbNyvk91kqFEFgNVV3vaxavygjGQ7
^C

````

[timthelion]

I appear to be experiencing what may be a kernel bug. While other fuse filesystems do work, ipfs's seems to always hang. This hang is quite serious, it prevents my laptop from going to sleep until I've TERMed the IPFS daemon.

When that happens I see something like this repeated in my dmesg output:

[545214.298311] fish D 0 31143 32659 0x00000004 [545214.298312] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d97c34040 ffff8d7dcc7de040 [545214.298314] ffff8d7f6ec18700 ffffa04a0b337c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298315] ffffffffc049cf2f 00000000fde3b180 ffffffffb461d514 ffff8d7dcc7de040 [545214.298317] Call Trace: [545214.298318] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298320] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298321] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298322] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298323] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298325] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298327] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298328] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298329] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298330] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298331] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298333] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298333] fish D 0 31145 32659 0x00000004 [545214.298334] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7dcc7de040 ffff8d7d8164e0c0 [545214.298336] ffff8d7f6ec18700 ffffa04a0b347c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298337] ffffffffc049cf2f 0000000098438c00 ffffffffb461d514 ffff8d7d8164e0c0 [545214.298339] Call Trace: [545214.298340] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298342] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298343] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298344] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298345] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298347] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298349] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298350] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298351] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298352] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298353] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298354] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298355] fish D 0 31148 32659 0x00000004 [545214.298356] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d8165d140 ffff8d7da4bf2000 [545214.298358] ffff8d7f6ec58700 ffffa04a0b367c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298359] ffffffffc049cf2f 0000000073591f00 ffffffffb461d514 ffff8d7da4bf2000 [545214.298361] Call Trace: [545214.298362] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298364] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298365] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298366] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298367] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298369] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298371] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298372] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298373] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298374] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298375] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298376] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298377] fish D 0 31150 32659 0x00000004 [545214.298378] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7da4bf2000 ffff8d7da1160080 [545214.298380] ffff8d7f6ec58700 ffffa04a0b377c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298381] ffffffffc049cf2f 0000000073591000 ffffffffb461d514 ffff8d7da1160080 [545214.298383] Call Trace: [545214.298384] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298386] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298387] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298388] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298389] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298391] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298393] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298394] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298395] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298396] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298397] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298398] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298399] fish D 0 31152 32659 0x00000004 [545214.298400] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7da1160080 ffff8d7daca64100 [545214.298402] ffff8d7f6ec58700 ffffa04a0b387c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298403] ffffffffc049cf2f 0000000073591600 ffffffffb461d514 ffff8d7daca64100 [545214.298405] Call Trace: [545214.298406] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298408] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298410] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298411] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298412] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298414] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298416] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298417] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298418] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298419] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298421] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298422] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298423] fish D 0 31153 32659 0x00000004 [545214.298424] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d8164e0c0 ffff8d7d8f4a0140 [545214.298426] ffff8d7f6ec18700 ffffa04a0b38fc38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298427] ffffffffc049cf2f 00000000fde3b300 ffffffffb461d514 ffff8d7d8f4a0140 [545214.298429] Call Trace: [545214.298430] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298433] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298434] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298435] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298436] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298438] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298440] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298441] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298442] [<ffffffffb44a2b3d>] ? wake_up_q+0x2d/0x60 [545214.298443] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298445] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298446] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b

[timthelion]

I appear to be experiencing what may be a kernel bug. While other fuse filesystems do work, ipfs's seems to always hang. This hang is quite serious, it prevents my laptop from going to sleep until I've TERMed the IPFS daemon.

When that happens I see something like this repeated in my dmesg output:

[545214.298311] fish D 0 31143 32659 0x00000004 [545214.298312] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d97c34040 ffff8d7dcc7de040 [545214.298314] ffff8d7f6ec18700 ffffa04a0b337c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298315] ffffffffc049cf2f 00000000fde3b180 ffffffffb461d514 ffff8d7dcc7de040 [545214.298317] Call Trace: [545214.298318] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298320] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298321] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298322] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298323] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298325] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298327] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298328] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298329] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298330] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298331] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298333] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298333] fish D 0 31145 32659 0x00000004 [545214.298334] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7dcc7de040 ffff8d7d8164e0c0 [545214.298336] ffff8d7f6ec18700 ffffa04a0b347c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298337] ffffffffc049cf2f 0000000098438c00 ffffffffb461d514 ffff8d7d8164e0c0 [545214.298339] Call Trace: [545214.298340] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298342] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298343] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298344] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298345] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298347] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298349] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298350] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298351] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298352] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298353] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298354] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298355] fish D 0 31148 32659 0x00000004 [545214.298356] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d8165d140 ffff8d7da4bf2000 [545214.298358] ffff8d7f6ec58700 ffffa04a0b367c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298359] ffffffffc049cf2f 0000000073591f00 ffffffffb461d514 ffff8d7da4bf2000 [545214.298361] Call Trace: [545214.298362] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298364] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298365] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298366] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298367] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298369] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298371] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298372] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298373] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298374] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298375] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298376] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298377] fish D 0 31150 32659 0x00000004 [545214.298378] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7da4bf2000 ffff8d7da1160080 [545214.298380] ffff8d7f6ec58700 ffffa04a0b377c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298381] ffffffffc049cf2f 0000000073591000 ffffffffb461d514 ffff8d7da1160080 [545214.298383] Call Trace: [545214.298384] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298386] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298387] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298388] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298389] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298391] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298393] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298394] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298395] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298396] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298397] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298398] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298399] fish D 0 31152 32659 0x00000004 [545214.298400] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7da1160080 ffff8d7daca64100 [545214.298402] ffff8d7f6ec58700 ffffa04a0b387c38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298403] ffffffffc049cf2f 0000000073591600 ffffffffb461d514 ffff8d7daca64100 [545214.298405] Call Trace: [545214.298406] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298408] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298410] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298411] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298412] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298414] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298416] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298417] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298418] [<ffffffffb45b682f>] ? handle_mm_fault+0xe0f/0x1560 [545214.298419] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298421] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298422] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b [545214.298423] fish D 0 31153 32659 0x00000004 [545214.298424] ffff8d7f60c6e800 ffff8d7f60c6e800 ffff8d7d8164e0c0 ffff8d7d8f4a0140 [545214.298426] ffff8d7f6ec18700 ffffa04a0b38fc38 ffffffffb49f784d ffff8d7e903ecb40 [545214.298427] ffffffffc049cf2f 00000000fde3b300 ffffffffb461d514 ffff8d7d8f4a0140 [545214.298429] Call Trace: [545214.298430] [<ffffffffb49f784d>] ? __schedule+0x23d/0x6d0 [545214.298433] [<ffffffffc049cf2f>] ? fuse_dentry_init+0x1f/0x30 [fuse] [545214.298434] [<ffffffffb461d514>] ? __d_alloc+0x134/0x1c0 [545214.298435] [<ffffffffb49f7d12>] ? schedule+0x32/0x80 [545214.298436] [<ffffffffb461de6f>] ? d_alloc_parallel+0x3df/0x4c0 [545214.298438] [<ffffffffb44a2b70>] ? wake_up_q+0x60/0x60 [545214.298440] [<ffffffffb4612907>] ? path_openat+0xeb7/0x14e0 [545214.298441] [<ffffffffb46142d1>] ? do_filp_open+0x91/0x100 [545214.298442] [<ffffffffb44a2b3d>] ? wake_up_q+0x2d/0x60 [545214.298443] [<ffffffffb45fe88b>] ? __check_object_size+0x10b/0x1dc [545214.298445] [<ffffffffb4601e57>] ? do_sys_open+0x127/0x210 [545214.298446] [<ffffffffb49fc5bb>] ? system_call_fast_compare_end+0xc/0x9b

[Stebalien]

It looks like something hanging on allocation in the kernel. Out of curiosity, do you have a swap?

[timthelion]

I think so:

````
timothy@yoga ~/p/p/ptt> free -h
total used free shared buffers cached
Mem: 7.7G 7.3G 384M 234M 60K 2.8G
-/+ buffers/cache: 4.6G 3.1G
Swap: 7.9G 5.4G 2.6G
timothy@yoga ~/p/p/ptt> sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 52A6E2FA-53C4-471D-90A3-A1F521C02C1A

Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 483532799 482482176 230.1G Linux filesystem
/dev/sda3 483532800 500117503 16584704 7.9G Linux swap

Command (m for help):

timothy@yoga ~/p/p/ptt> cat /etc/fstab

/etc/fstab: static file system information.

#

Use 'blkid' to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

#

/ was on /dev/sda2 during installation

UUID=0e6711fa-750f-458f-81e9-b84252109188 / btrfs defaults 0 1

/boot/efi was on /dev/sda1 during installation

UUID=0513-2414 /boot/efi vfat umask=0077 0 1

swap was on /dev/sda3 during installation

UUID=de67d2b1-42c1-46ef-9ea8-47861edbd3a6 none swap sw 0 0
UUID=0513-2414 /boot/efi vfat defaults 0 1
timothy@yoga ~/p/p/ptt>
````

[timthelion]

But I also have an odd numbered kernel. I have heard rumors that those are bad luck: http://www.linfo.org/kernel_version_numbering.html

[Stebalien]

So, by "always hangs" I assume you mean it literally never works? Related, do you have any idea what "fish" means here?

[Stebalien]

Not the same bug but another VFS/sleep bug: https://bugzilla.samba.org/show_bug.cgi?id=11290

[timthelion]

I didn't even notice the fish. Fish is the interactive shell I use: https://fishshell.com/ it would be interesting if this bug only showed up with a certain shell wouldn't it ;) but this must have something to do with ipfs, because other fuse file systems work (I tested encfs just now). (Also, the sleep problem goes away when I shut down the daemon...)

So far, it has always hung for me. However, it is quite difficult to do any reasonable testing given the degree of the hanging. I cannot even ^C out of it.

[Stebalien]

That CIFS bug also mentions fish so I think it's some kernel thing. At this point, you'll probably have better luck taking this to the kernel mailing list as it's clearly a kernel bug.

Random things I'd try if I were experiencing this bug:

1. Try disabling swap.
2. Try with low memory pressure (just after boot without starting anything else up).
3. Try changing the IFPS mount point to a different filesystem (shouldn't make a difference...).
4. Try it offline.

Unfortunately, I think that's the extent of the advice I can give you without being a kernel developer and without being able to reproduce this bug.

[whyrusleeping]

(yay, another fish user :D )

[whyrusleeping]

I will say that fish might be partially to blame here (obviously a kernel bug is a kernel bug), it gathers a bunch more information about files when listing directories and cd'ing into them than other shells do.

[Kubuxu]

It is possible that it doesn't like the permission denied /ipfs gives and/or we have some bug in our handler.

[kvm2116]

I think I am running into the same error mentioned here.

Without ipns mount: I can get the file using
"ipfs get /ipns/Qma5vsbjS3JVE5qnd3Mu8wx6r6ofLFd8jHEjfzf7DcuZS4"

With ipns mount: cat command hangs
"cat /ipns/Qma5vsbjS3JVE5qnd3Mu8wx6r6ofLFd8jHEjfzf7DcuZS4/hello.txt"

Not entirely sure if this is a design issue with IPNS mount. Any thoughts?

[kvm2116]

I believe this bug has been resolved:
https://github.com/ipfs/go-ipfs/pull/5327

[Stebalien]

That should have caused the resolution to fail immediately... Odd.