Finding cores in ceph-helper is even more convoluted .....

Finding cores in ceph-helper is even more convoluted .....

[Willem Jan Withagen]

@dzafman
I'm running into a small snag when running a full test:
I've added a line to show what is in the directory
```
6:
/home/jenkins/workspace/ceph-master/qa/standalone/ceph-helpers.sh:172:
teardown:  pwd
6: /home/jenkins/workspace/ceph-master/build/src/test
6:
/home/jenkins/workspace/ceph-master/qa/standalone/ceph-helpers.sh:173:
teardown:  ls .
6: CMakeFiles
6: CTestTestfile.cmake
6: Makefile
6: ObjectMap
6: bench
6: cls_hello
6: cls_lock
6: cls_log
6: cls_lua
6: cls_numops
6: cls_rbd
6: cls_refcount
6: cls_replica_log
6: cls_rgw
6: cls_sdk
6: cls_statelog
6: cls_version
6: cmake_install.cmake
6: common
6: compressor
6: core.ceph_test_objectsto.51398
6: core.unittest_bufferlist.50899
6: core.unittest_signals.50922
6: core.unittest_texttable.51005
```
CWD = build/src/test

So the setup routine already starts to fail in teardown because there
where cores, left from previous tests.
Question is how to find out who generated the cores, and do they
actually belong to the current test.
Complexing problem is that `%N` only uses the first 19 chars of a
process name.

perhaps we should set core-names to something like "core.${testname}"??

--WjW

Re: Finding cores in ceph-helper is even more convoluted .....

[Willem Jan Withagen]

And something to be aware of as well:

wjw@cephdev:~/master % sysctl -w kern.corefile=core.%N.%P
kern.corefile: core.%N
sysctl: kern.corefile=core.%N.%P: Operation not permitted

Setting core-name output only works as root.

--WjW

On 11-8-2017 10:51, Willem Jan Withagen wrote:
> @dzafman
> I'm running into a small snag when running a full test:
> I've added a line to show what is in the directory
> ```
> 6:
> /home/jenkins/workspace/ceph-master/qa/standalone/ceph-helpers.sh:172:
> teardown:  pwd
> 6: /home/jenkins/workspace/ceph-master/build/src/test
> 6:
> /home/jenkins/workspace/ceph-master/qa/standalone/ceph-helpers.sh:173:
> teardown:  ls .
> 6: CMakeFiles
> 6: CTestTestfile.cmake
> 6: Makefile
> 6: ObjectMap
> 6: bench
> 6: cls_hello
> 6: cls_lock
> 6: cls_log
> 6: cls_lua
> 6: cls_numops
> 6: cls_rbd
> 6: cls_refcount
> 6: cls_replica_log
> 6: cls_rgw
> 6: cls_sdk
> 6: cls_statelog
> 6: cls_version
> 6: cmake_install.cmake
> 6: common
> 6: compressor
> 6: core.ceph_test_objectsto.51398
> 6: core.unittest_bufferlist.50899
> 6: core.unittest_signals.50922
> 6: core.unittest_texttable.51005
> ```
> CWD = build/src/test
> 
> So the setup routine already starts to fail in teardown because there
> where cores, left from previous tests.
> Question is how to find out who generated the cores, and do they
> actually belong to the current test.
> Complexing problem is that `%N` only uses the first 19 chars of a
> process name.
> 
> perhaps we should set core-names to something like "core.${testname}"??
> 
> --WjW
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Finding cores in ceph-helper is even more convoluted .....

[Mykola Golub]

On Fri, Aug 11, 2017 at 10:51:05AM +0200, Willem Jan Withagen wrote:

> Question is how to find out who generated the cores, and do they
> actually belong to the current test.

In FreeBSD case you can use procstat(1) to get process information
from the core.

E.g. `procstat -b core` will show path to the binary, `procstat -c core`
will show command line options, and `procstat -e core` will show
environment variables.

-- 
Mykola Golub

Re: Finding cores in ceph-helper is even more convoluted .....

[Willem Jan Withagen]

On 11-8-2017 18:26, Mykola Golub wrote:
> On Fri, Aug 11, 2017 at 10:51:05AM +0200, Willem Jan Withagen wrote:
> 
>> Question is how to find out who generated the cores, and do they
>> actually belong to the current test.
> 
> In FreeBSD case you can use procstat(1) to get process information
> from the core.
> 
> E.g. `procstat -b core` will show path to the binary, `procstat -c core`
> will show command line options, and `procstat -e core` will show
> environment variables.

Thanx for the pointer. I keep forgetting that procstat exists, let alone
what it can do.

Perhaps one of these will help to determine if any of the cores is
actually part of the current test, which different from just knowing
it's name and things. Could be that the environment gives enough to do
some selection on it.

It is going to rain a lot during the weekend. So probably will have some
toy time to spare.

--WjW