Some pcp clients are happy to use PM_CONTEXT_LOCAL with a small handful
of C .so PMDA's (linux_proc e.g.), but are unhappy that these pmdas are
only packaged in the central 'pcp' rpm, which has perl/python/etc.
prerequisites. We should break up the 'pcp' rpm so that the footprint
for small clients is small.
- the default pmns/root is either not used at all, or is provided in
generated capacity by the build, instead of being generated during
first -pmcd- startup
- pmdas that need perl are separated out into at least one subrpm;
- plain C (no-further-big-prereqs) pmdas are separated out
into at least one subrpm (without depending on base pcp)
- if needed, libpcp adjusted PM_CONTEXT_LOCAL can use the pmda
subrpms without needing other pcp binaries / nontrivial config
- probably: invent a mechanism where libpcp can find .so pmdas
by searching the pmda directories rather than scraping pmcd.conf,
e.g., a __pmSpecLocalPMDA keyword "scan", searching $PMDADIR and
stdpmid.pcp / stdpmid.local?
(This should also shrink the hurdles for a default-on local-pmlogger
*** Bug 1184403 has been marked as a duplicate of this bug. ***
Other places where improvements should be made:
- remove the direct dependency in libpcp on the Avahi libraries - all discovery/advertising methods should become runtime configurable and extensible outside of PCP.
- remove the direct dependency in libpcp on NSS/SSL, Dave has completed almost all of the work for this now - someone just needs to go the last dlopen step.
- pmwebd seems to have acquired a dependency chain that includes some 10-15 X11/desktop/font libraries, and associated rpm dependencies, as a result of using the Cairo library. Its resident memory footprint has doubled as a result, combined with the switch to using C++ - would be worth considering a more dynamic plugin model for pmwebd, as people will want to use it on servers without all those X11 rpms.
The "invent a mechanism" line in original report wont fly as described I suspect - IIRC pmcd.conf was used because these PMDAs are known to have root namespace entries, which is required in local context mode also - so a design which considers the metric namespace would be needed.
Apprx. all those libraries are already split into separate -libs type
subrpms, so beyond their genuinely useful function do not constitute
unnecessary or peculiar overheads. One should need a pretty well-justified
case to justify reinventing ordinary dynamic linking.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.
More information and reason for this action is here:
pcp-3.10.5-1.fc22 has been submitted as an update for Fedora 22.
pcp-3.10.5-1.fc21 has been submitted as an update for Fedora 21.
pcp-3.10.5-1.fc20 has been submitted as an update for Fedora 20.
pcp-3.10.5-1.el5 has been submitted as an update for Fedora EPEL 5.
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing pcp-3.10.5-1.el5'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
pcp-3.10.6-1.fc22 has been submitted as an update for Fedora 22.
pcp-3.10.6-1.fc21 has been submitted as an update for Fedora 21.
pcp-3.10.6-1.el5 has been submitted as an update for Fedora EPEL 5.
Not a huge deal, but this bug shouldn't be considered fixed when associated with OS versions where the pcp -> pcp-compat -> pcp-mostly-everything dependency chain is active.
pcp-3.10.6-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.6-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.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.