Description of problem: When starting PCP clients with -L, there's a needless PMCD connection attempted: localhost:~> strace -ff pmprobe -L -v hinv.machine 2>&1 | grep -i socket socket(PF_LOCAL, SOCK_STREAM, 0) = 3 setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0 connect(3, {sa_family=AF_LOCAL, sun_path="/var/lib/pcp/tmp/pmcd/root.socket"}, 110) = -1 EACCES (Permission denied) localhost:~> There are also some less significant initialization paths which could perhaps be eliminated: localhost:~> strace -ff pmprobe -L -v hinv.machine 2>&1 | grep -i /var | grep // access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/linux/pmda_linux.so", F_OK) = -1 ENOENT (No such file or directory) access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/linux/pmda_linux.so.so", F_OK) = -1 ENOENT (No such file or directory) access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/mmv/pmda_mmv.so", F_OK) = -1 ENOENT (No such file or directory) access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/mmv/pmda_mmv.so.so", F_OK) = -1 ENOENT (No such file or directory) access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/jbd2/pmda_jbd2.so", F_OK) = -1 ENOENT (No such file or directory) access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/jbd2/pmda_jbd2.so.so", F_OK) = -1 ENOENT (No such file or directory) localhost:~> Version-Release number of selected component (if applicable): pcp-3.10.6-2.el7.x86_64
Info, no insight. The connect() coming from the "root" pmda code (recent stuff) ... (gdb) where #0 connect () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff7b9a7a3 in __pmConnect () from /usr/lib/libpcp.so.3 #2 0x00007ffff580c193 in pmdaRootConnect () from /usr/lib/libpcp_pmda.so.3 #3 0x00007ffff55def46 in linux_init () from /var/lib/pcp/pmdas/linux/pmda_linux.so #4 0x00007ffff7ba02f6 in __pmConnectLocal () from /usr/lib/libpcp.so.3 #5 0x00007ffff7b70ea4 in pmNewContext () from /usr/lib/libpcp.so.3 #6 0x000000000040102f in ?? () #7 0x00007ffff77b3a40 in __libc_start_main (main=0x400ee0, argc=4, argv=0x7fffffffde78, init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7fffffffde68) at libc-start.c:289 #8 0x0000000000401929 in ?? ()
(In reply to Marko Myllynen from comment #0) > Description of problem: > When starting PCP clients with -L, there's a needless PMCD connection > attempted: Yep. Is there an actual problem here though? PMDAs started via local context are started in the same way as DSO PMDAs running under PMCD ... so there's no way to tell whether this connection will be needed or not, so we have to attempt it. Its safe to fail this connection attempt though, just means some functionality is not available. > access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/linux/pmda_linux.so", F_OK) = > -1 ENOENT (No such file or directory) Ken, this is coming from approx line 345 in connectlocal.c::__pmConnectLocal - certainly the ordering of the search could be fixed (starting from the innermost "if" which is nowadays the most likely DSO path from pmcd.conf). However, it may be the case nowadays that only that innermost "if" can be true - do we always use full paths to DSOs in pmcd.conf now? (I think we do...) In that case, we can drop ~10 lines of code there, I think.
(In reply to Nathan Scott from comment #2) > (In reply to Marko Myllynen from comment #0) > > Description of problem: > > When starting PCP clients with -L, there's a needless PMCD connection > > attempted: > > Yep. Is there an actual problem here though? No, haven't see this causing anything, merely a micro-optimization.
(In reply to Marko Myllynen from comment #0) > Description of problem: > When starting PCP clients with -L, there's a needless PMCD connection > attempted: > sun_path="/var/lib/pcp/tmp/pmcd/root.socket"}, 110) = -1 EACCES (Permission To clarify something from Kens note in #c1 that I missed - this is a pmdaroot connection attempt and not a pmcd connection attempt as was initially thought. This is not something we can skip, PMDAs running in DSO mode can use pmdaroot services too. > access("/var/lib/pcp/pmdas//var/lib/pcp/pmdas/linux/pmda_linux.so", F_OK) = > -1 ENOENT (No such file or directory) I've tweaked the code (commit da4d9c82db70a) such that the ordering of DSO lookups now hits the correct paths first and we no longer see these access(2) attempts with dodgey paths using the default DSO table.
pcp-3.11.6-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0ad9e5194
pcp-3.11.6-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-15f10c1698
pcp-3.11.6-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a7626fa3f1
pcp-3.11.6-1.el5 has been submitted as an update to Fedora EPEL 5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a7454a07e7
pcp-3.11.6-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a7626fa3f1
pcp-3.11.6-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-15f10c1698
pcp-3.11.6-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0ad9e5194
pcp-3.11.6-1.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a7454a07e7
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
pcp-3.11.6-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.11.6-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.11.6-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.11.6-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.