Scenario: - server serves files with Samba 3.6 - client mounts with smbfs Problem description: - change directory to the smbfs-mounted filesystem on client - try to start vim (not vi!), evince, libreoffice or similar (you don't need to open a file from smbfs!) - truss shows that it hangs calling openat in infinite loop truss output: openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3) openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3) openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3) [ repeating infinitely ] Further details: - while current working directory is inside a smbfs-mountpoint, it is also not possible to open files on locally mounted filesystems Mount description in /etc/fstab: //username@servername/remotefs /net/server/remotefs smbfs rw,noauto,-N,-W=DOMAIN,-u=username,-g=groupname 0 0 (*) remark: I use noauto because there is a race condition with the network initialization which forces me to mount after a 10s sleep in /etc/rc.local (I think this problem is not related with the one described here) Disclaimer: It might be a samba misconfiguration. I am not fully sure what happens here. -- Martin
This has been a problem for me since early 2015, and it appears quite reliably with vi from /usr/bin, too. My SMBFS-Options are: rw,noexec,nosuid,-f=0666,-d=0777,-u=nobody,-g=nobody and the share is provided by Samba version 3.6.12-1.fc17 with no problems whatsoever when connecting from Linux or Windows. Truss gives me an infinite stream of identical messages like: openat(AT_FDCWD,"�.db",O_CLOEXEC,00) = 499 (0x1f3) Attaching gdb to the locked process produces the following backtrace: #0 0x2822b0a1 in _openat () from /lib/libc.so.7 #1 0x281d8ac8 in open () from /lib/libc.so.7 #2 0x281d6f34 in _citrus_map_file () from /lib/libc.so.7 #3 0x281d31d0 in _citrus_mapper_set_persistent () from /lib/libc.so.7 #4 0x281d33c5 in _citrus_mapper_set_persistent () from /lib/libc.so.7 #5 0x281a8951 in _citrus_lookup_factory_convert () from /lib/libc.so.7 #6 0x281a65d5 in __bsd_iconv_open () from /lib/libc.so.7 #7 0x281a6543 in __bsd_iconv_open () from /lib/libc.so.7 #8 0x08052826 in conv_enc (sp=0x28834a00, option=23, enc=0x288331c8 "UTF-8") at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:405 #9 0x080520be in conv_init (orig=0x28834400, sp=0x28834a00) at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:360 #10 0x0806df71 in screen_init (gp=0x28803000, orig=0x28834400, spp=0x28803018) at /usr/src/usr.bin/vi/../../contrib/nvi/common/screen.c:118 #11 0x080a20c9 in v_ecl_init (sp=0x28834400) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:638 #12 0x080a1a32 in v_ecl_log (sp=0x28834400, tp=0x28862100) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:587 #13 0x080a17ec in v_ex (sp=0x28834400, vp=0xbfbfe538) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:376 #14 0x080b9174 in vi (spp=0xbfbfe838) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vi.c:230 #15 0x08060e23 in editor (gp=0x28803000, argc=0, argv=0xbfbfe954) at /usr/src/usr.bin/vi/../../contrib/nvi/common/main.c:422 #16 0x0804d5e0 in main (argc=1, argv=0xbfbfe950) at /usr/src/usr.bin/vi/../../contrib/nvi/cl/cl_main.c:119 Digging deeper into the issue, I also linked vi against a temporary libc built with debug-information, but gdb threw an error related to the format of the symbol table, so the following information may have to be taken with a grain of salt: (gdb) bt #0 0x2822b0a1 in ?? () #1 0x281d8ac8 in ?? () #2 0xffffff9c in ?? () #3 0xbfbfc958 in ?? () #4 0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=0x8, node=0x282d2dc0) at /usr/src/lib/libc/jemalloc_extent.c:25 #5 0x281d6f34 in ?? () #6 0xbfbfc958 in ?? () #7 0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=0x282d2b88, node=0x284000c8) at /usr/src/lib/libc/jemalloc_extent.c:25 #8 0x281d31d0 in ?? () #9 0xbfbfc950 in ?? () #10 0xbfbfc958 in ?? () #11 0x2829aac0 in ?? () #12 0xbfbfcddc in ?? () #13 0x288a700c in ?? () #14 0x080e3b30 in optarg@@FBSD_1.0 () #15 0x00000000 in ?? ()
P.s.: This bug persists on 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 i386, and does it really belong to the "kern" category?
See also the penultimate comment regarding a hang in vim made on 18th August 2015: https://github.com/vim/vim/issues/330 The backtrace is very similar to mine.