Date: Tue, 5 Nov 2019 10:15:12 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: "Kevin P. Neal" <kpn@neutralgood.org> Cc: Pete French <petefrench@ingresso.co.uk>, freebsd-stable@freebsd.org, 000.fbsd@quip.cz Subject: Re: python dameon coredumps when started from boot, but not by hand Message-ID: <4010794E-F6C7-47DB-9746-8A6F63C957F7@dons.net.au> In-Reply-To: <20191104151555.GB60435@neutralgood.org> References: <b2d1c84d-36a5-e5b5-4c88-0c458ea668e1@quip.cz> <E1iRdgM-0000tH-T1@dilbert.ingresso.co.uk> <20191104151555.GB60435@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 5 Nov 2019, at 01:45, Kevin P. Neal <kpn@neutralgood.org> wrote: >=20 > 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! >=20 > 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.=20 >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4010794E-F6C7-47DB-9746-8A6F63C957F7>