freebsd stable - Nov 2019 - python dameon coredumps when started from boot, but not by hand

> On 5 Nov 2019, at 01:45, Kevin P. Neal <kpn at neutralgood.org>
wrote:
> 
> On Mon, Nov 04, 2019 at 02:50:14PM +0000, Pete French wrote:
>> Soo, I tried this on my desktop machine, and it doesnt coredump, but
>> nor does it try and lauch the second python process, so a bit of a
failed
>> test there!
> 
> You can use ktrace to see what system calls it is doing. Sometimes it
> is helpful to know that just before things went wrong a process tried
> to open some particular file and failed, for example. 
> 
> Be sure to use the -i flag so children of the traced process also get
> traced. I also suggest "-f <path>" so the trace file
doesn't end up
> in some weird location. During boot I'd guess that the trace file would
> be in "/", but putting it elsewhere may be helpful. Just so long
as the
> filesystem has already been mounted at that point in the boot.
This would also capture the stderr output, and should be pretty easy to shoe
horn into the rc.d file.

Nice thinking!

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

On 04/Nov/2019 23:45, O'Connor, Daniel wrote:
> This would also capture the stderr output, and should be pretty easy to
shoe horn into the rc.d file.
> 
> Nice thinking!
Just picking this up again, I have tried a few things, but am unable to
actually get this to work in the rc.d file, any suggestions? RC is quite
clever and seems to read the hash-pling line from the script and compare
it to the value set for the interpreter, so I cant simply add ktrace in
front on the interpreter itself. I tried knocking up a simple wrapper
script, but that didnt work too well (didnt become a daemon propely) and
I am wary of chnaging too much as I want the test to be as similar to
the actual bug situation as possible.

ktrace generates data at a spectacular rate thoughnthough doesnt it ? :-)

-pete.