On 05/07/16 10:07, Nathan Scott wrote:
...
I've pushed in a fix for 722, 'twas a memory corruption problem.
Hi Nathan,
722 is still failing on some hosts, e.g. on grundy I'm seeing this
(running the container test by hand)
kenj@grundy-dmz:~/src/pcp/qa> TEST_SET_CONTAINER=abc012345 python
src/test_set_source.python
== Test ==
Hosts: None
Archives: None
Container: abc012345
Traceback (most recent call last):
File "src/test_set_source.python", line 93, in <module>
test.connect()
File "src/test_set_source.python", line 88, in connect
self.context = pmapi.pmContext.fromOptions(self.opts, sys.argv)
File "/usr/local/lib/python2.6/site-packages/pcp/pmapi.py", line
1204, in fromOptions
context = builder(typed, source)
File "/usr/local/lib/python2.6/site-packages/pcp/pmapi.py", line
1162, in __init__
raise pmErr(self._ctx, [target])
pcp.pmapi.pmErr: Operation not supported ['local:']
And similar results on vm14 and vm21.
I saw 1108 fail once, but never again & running it in a loop isn't
able to hit it, so I'm wondering if its related to some state left
behind from an earlier test. I'll keep digging.
Your guess seems correct ... the 1108.full records show pmnewlog trying
to kill off TWO pmloggers ... this is badness ... I've made a change to
pmnewlog to detect this and report the details and I hope this will
identify where the additional process is coming from.
|