New Comment on Issue #github

[pcp:master] New Comment on Issue #118 reported pmDestroyContext: pthread_mutex_destroy(c_lock) failed: Device or resource busy, failed second try as well ( https://github.com/performancecopilot/pcp/issues/118 )
By fche ( https://github.com/fche ) :

The libc_recv call stack, just happen to have it saved in my terminal:

(gdb) bt #0 0x00007f29a96b610f in __libc_recv (fd=fd@entry=11, buf=buf@entry=0x7f29700090ac, n=n@entry=12, flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28 #1 0x00007f29a992155e in recv (__flags=0, __n=12, __buf=0x7f29700090ac, __fd=11) at /usr/include/bits/socket2.h:44 #2 __pmRecv (fd=fd@entry=11, buffer=buffer@entry=0x7f29700090ac, length=length@entry=12, flags=flags@entry=0) at secureconnect.c:1597 #3 0x00007f29a98dfff2 in pduread (fd=fd@entry=11, buf=buf@entry=0x7f29700090ac ")\177", len=len@entry=12, part=part@entry=0, timeout=timeout@entry=10) at pdu.c:212 #4 0x00007f29a98e0c9f in __pmGetPDU (fd=11, mode=mode@entry=0, timeout=10, result=result@entry=0x7f28a77fd4b8) at pdu.c:495 #5 0x00007f29a98e46ad in pmLookupName (numpmid=numpmid@entry=1, namelist=namelist@entry=0x7f29700050b0, pmidlist=0x7f29700050d0) at pmns.c:1703 #6 0x00007f29a990dae2 in bind_expr (n=n@entry=2, np=0x7f297000a1b0) at derive.c:616 #7 0x00007f29a990d9a8 in bind_expr (n=n@entry=2, np=0x7f2970009020) at derive.c:578 #8 0x00007f29a990d9a8 in bind_expr (n=n@entry=2, np=0x7f297000a200) at derive.c:578 #9 0x00007f29a990d9a8 in bind_expr (n=n@entry=2, np=0x7f297000a320) at derive.c:578 #10 0x00007f29a990ff8f in __dmopencontext (ctxp=ctxp@entry=0x7f2968000b20)

so derived-metric setup related, so probably early in pmNewContext. The hang must have started Oct. 15, and is probably relevant. I believe at least one prior instance of this occurred at the end of September.

pmmgr can create multiple contexts to the same host, if the discovery / explicit-list happens to return the equivalent pcp:// url / hostname / IPs multiple times.