Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2018 11:43:50 +0100
From:      Willem Jan Withagen <wjw@digiware.nl>
To:        cem@freebsd.org
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: setting distinct core file names
Message-ID:  <7b2b134c-3fd3-6212-b06a-81003361e083@digiware.nl>
In-Reply-To: <CAG6CVpVXsbPCTAxu9j7t8_i17uP_55W9a_NuLzyNCGS=qo5C7A@mail.gmail.com>
References:  <84f498ff-3d65-cd4e-1ff5-74c2e8f41f2e@digiware.nl> <CAG6CVpVXsbPCTAxu9j7t8_i17uP_55W9a_NuLzyNCGS=qo5C7A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 27-11-2018 21:46, Conrad Meyer wrote:
> One (ugly) trick is to use multiple filesystem links to the script
> interpreter, where the link names distinguish the scripts.  E.g.,
> 
> $ ln /bin/sh /libexec/my_script_one_sh
> $ ln /bin/sh /libexec/my_script_two_sh
> $ cat myscript1.sh
> #!/libexec/my_script_one_sh
> ...
> 
> Cores will be dumped with %N of "my_script_one_sh."

Neat trick... got to try and remember this.
But it is not the shell scripts that are crashing...

When running Ceph tests during Jenkins building some 
programs/executables intentionally crash leaving cores.
Others (scripts) use some of these programs with correct input and 
should NOT crash. And test during startup and termination that there are 
no cores left.

One jenkins test run takes about 4 hours when not executed in parallel. 
I'm testing 4 version multiple times a day to not have this huge list of 
PRs the go thru when testing fails.

But the intentional cores and the failure cores here collide.
And when I have a core program_x.core I can't tell if they are from a 
failure or from an intentional crash.

Now if could tell per program  how to name its core that would allow me 
to fix the problem, without overturning the complete Ceph testing 
infrastructure and still keep parallel tests.

It would also help in that "regular" cores just keep going the way the 
are. So other application still have the same behaviour. And are still 
picked up by periodic processing.

--WjW

> Best,
> Conrad
> On Tue, Nov 27, 2018 at 9:29 AM Willem Jan Withagen <wjw@digiware.nl> wrote:
>>
>> Hi,
>>
>> Looking at core(5) and sysctl it looks like these are system wide
>> settings....
>>
>> Is there a possibility that a program can set its own corefile name (and
>> path?)
>>
>> During parallel testing I'm running into these scripts that generate
>> cores, but they end up all in the same location. But it would be nice if
>> I could one way or another determine which file came from what script.
>>
>> But for that I would need to be able to set something like
>>          %N."script".core
>> as the core name. I could then put that in then ENV of the script and
>> the program would pick it up and set its own corefile name.
>>
>> Possible??
>> --WjW
>> _______________________________________________
>> freebsd-hackers@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b2b134c-3fd3-6212-b06a-81003361e083>