On 26/02/16 10:18, Mark Goodwin wrote:
...
This gets pretty messy for mortal users using local contexts - they can
read
the global system cache, but only write it back out where they have
permissions,
e.g. in their $home.
I think this is likely to be a real corner case ... (a) only DSO pmdas
are in the frame for local contexts, (b) most of the "odd" uid case
pmdas are not DSOs, (c) the status quo works with read-only access for
most of these pmdas provided they are started first from pmcd (so the
files get created and populated, with their 644 mode)
If a private cache diverges from global, reconcilliation could get messy.
IMO it'd be better to just not have alternate caches - the global cache
needs
to function read-only.
I was thinking the PMDA code might decide where to put the cache files
(so the API option, not the environment variable option) ... so the
caches would not diverge, but this would not help the Mary the Mortal
with a local context use (it is not better/worse than
/var/lib/pcp/config/pmda)
IIRC there was also a mutex issue with the PMDA caches - readers are not
protected
from concurrent updates - did that ever get fixed?
It never was addressed ... because for the most common use cases, just
one PMDA is ever updating a particular indom cache file.
Now if DSOs with local contexts can start to write into a shared indom
cache, the assumption is broken and the issue would have to be revisited.
Personally I'd rather not do this.
|