I think I've narrowed down this issue. This happened after compiling
ntirpc and nfs-ganesha separately, then later compiling nfs-ganesha
with submodule. DanG made some changes to the system library inclusion
cmake in -dev-4.
My solution was to rm -rf lib64 between builds. In looking around, I'd
noticed over a year's worth of old libntirpc versions in it. The linker
should pick the correct one, but....
On 8/17/17 9:57 AM, Malahal Naineni wrote:
Bill, I tried to reproduce without gdb. It goes down after few seconds (around 30) due to svc_rqst_epoll_loop() waiting for about 29 seconds. I tried with gdb as well, it came out too. I saw only few threads (about 10) after sending the signal. Can you
tell me how I can reproduce without 'gdb' ? (gpfs fsal has some issues with gdb at times..)
Regards, Malahal.
On Thu, Aug 17, 2017 at 4:56 PM, William Allen Simpson <william.allen.simp...@gmail.com
<mailto:william.allen.simp...@gmail.com>> wrote:
[...]
Retested with V2.6-dev.4a
Took a long shower, 6:35-7:05, to ensure plenty of time. Same result.
Exactly 271 danging threads, almost all waiting in nfs_rpc_dequeue_req.
But the exact same code just verified on both centos and CEA at:
# View Change <https://review.gerrithub.io/374060
<https://review.gerrithub.io/374060>>
Was there a required config parameter change?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
