From owner-freebsd-hackers@freebsd.org Wed Nov 28 10:44:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E27D5115023D for ; Wed, 28 Nov 2018 10:44:02 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD9BC6EEE3; Wed, 28 Nov 2018 10:44:01 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 163A2B3789; Wed, 28 Nov 2018 11:43:53 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRtlTQs-eWsZ; Wed, 28 Nov 2018 11:43:51 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 9659AB3777; Wed, 28 Nov 2018 11:43:51 +0100 (CET) Subject: Re: setting distinct core file names To: cem@freebsd.org Cc: "freebsd-hackers@freebsd.org" References: <84f498ff-3d65-cd4e-1ff5-74c2e8f41f2e@digiware.nl> From: Willem Jan Withagen Message-ID: <7b2b134c-3fd3-6212-b06a-81003361e083@digiware.nl> Date: Wed, 28 Nov 2018 11:43:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CD9BC6EEE3 X-Spamd-Result: default: False [-4.70 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[digiware.nl]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-1.41)[ipnet: 2000::/6(-3.97), asn: 12552(-3.06), country: SE(-0.02)]; MX_GOOD(-0.01)[cached: smtp.digiware.nl]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12552, ipnet:2000::/6, country:SE]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 10:44:03 -0000 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 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"