Would be nice not to run pmcpp for PM_CONTEXT_LOCAL
mvollmer opened this issue · 13 comments
Creating a PM_CONTEXT_LOCAL will run pmcpp. This raises some eyebrows, especially since pmcpp is not usually packaged together with libpcp.
For example, the Cockpit unit tests use their own mock pmda and nothing else (no daemon, no other pmda, etc). But they still need the pmcpp binary from a full PCP installation.
On 21/01/15 21:20, Marius Vollmer wrote:
Creating a PM_CONTEXT_LOCAL will run pmcpp. This raises some eyebrows,
especially since pmcpp is not usually packaged together with libpcp.For example, the Cockpit unit tests use their own mock pmda and nothing
else (no daemon, no other pmda, etc). But they still need the pmcpp
binary from a full PCP installation.
pmcpp is needed because we need to load the Performance Metrics Name
Space (PMNS) and this is processed with pmcpp before being read.
Would moving pmcpp to the libpcp package resolve this issue? That's a
simple and logical change in terms of PCP packaging and function.
Would moving pmcpp to the libpcp package resolve this issue?
I would say so, if that doesn't increase the dependencies of the libpcp package. Of course, spawning processes is still a bit unexpected, but I can't point at any concrete problems that it causes. Maybe @stefwalter can.
On Fedora at least, pmcpp seems to depend on avahi, nss, nspr, cyrus-sasl, and maybe others. This might just be from a sloppy build, though.
Should I move this to Fedora?
pmcpp is not available on Atomic. This prevents us from using pcp-libs on Atomic, even if we do bundle the library with Cockpit.
Hmmm, I wonder does one need to run pmcpp when connecting to pmcd on another host?
Hmmm, I wonder does one need to run pmcpp when connecting to pmcd on another host?
No. Reading archives also doesn't need it.
This prevents us from using pcp-libs on Atomic, even if we do bundle the library with Cockpit.
But if we bundle the library, we can also bundle pmcpp right next to it. (And fix the library to find it.)
True, if we bundle the library we can rewrite it :)
True, if we bundle the library we can rewrite it :)
Actually, libpcp looks at $PCP_ALT_PMCPP and also things like PCP_BINADM_DIR in general can be overwritten in the environment. So we should be good with relocating libpcp
Hmmm, the only thing that launching pmcpp is used for is removing the license comment at the top of /var/lib/pcp/pmns/root_linux
Is it true that the linux pmda is useless without the /var/lib/pcp/pmns/root_linux file, which isn't even shipped in the same package either?
On 21/01/15 22:56, Stef Walter wrote:
Is it true that the linux pmda is useless without the
/var/lib/pcp/pmns/root_linux file, which isn't even shipped in the same
package either?
Hold on ... root_linux is in the same package as the linux PMDA ... if
you want to use PM_CONTEXT_LOCAL you need to install the libraries and
the PMDAs you want to use with PM_CONTEXT_LOCAL.
So installing libpcp3-dev* and pcp is sort of mandated. Now this will
pull in a lot of other dependencies (from pcp) that probably aren't
needed in your use context.
Since I'm ignorant as to what you're trying to do, could someone please
explain that, and then we can see if some package restructuring might
help reduce the barrier to using the PCP services.
This is more or less orthogonal to the original pmcpp question that I'll
address in a different email response.
Cheers, Ken.
On 21/01/15 22:54, Stef Walter wrote:
Hmmm, the only thing that launching pmcpp is used for is removing the
license comment at the top of /var/lib/pcp/pmns/root_linux
This is not strictly true.
The pmns files can contain any valid cpp directive, including #include
and #define, and expect expansion of #defined vars to work. This is
important for the installation and removal of optional PMDAs that are a
key part of PCP, but outside the scope of any use that is confined to
PM_CONTEXT_LOCAL.
Now in the case on PM_CONTEXT_LOCAL the pmns that is processed by pmcpp
is /var/lib/pcp/pmns/root (not root_linux), which on my system contains
no cpp directives or controls (can you confirm this is the case for your
setup)?
I think this will always be the case for current PCP versions (it was
not always so), which introduces the possibility of a fast-path for
PM_CONTEXT_LOCAL that would not use pmcpp.
Would that be of interest? And how might we test that in your environment?
I've removed much of the use of pmcpp in the code ... and in particular PM_CONTEXT_LOCAL does not require pmcpp. This is done and tested in my git repo and should flow to github shortly after review and merging.
I'm closing this issue ... if there are remaining packaging issues, please open a new issue so we can focus the discussion there.
Cheers, Ken.
I've removed much of the use of pmcpp in the code ... and in particular PM_CONTEXT_LOCAL does not require pmcpp.
Nice, thanks!