Date: Thu, 31 Oct 2019 10:22:19 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: Pete French <petefrench@ingresso.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: python dameon coredumps when started from boot, but not by hand Message-ID: <872D68EE-143D-41F3-BC22-45AC4F7E934F@dons.net.au> In-Reply-To: <E1iPxYg-0001ID-Gz@dilbert.ingresso.co.uk> References: <E1iPxYg-0001ID-Gz@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 31 Oct 2019, at 10:09, Pete French <petefrench@ingresso.co.uk> = wrote: > I opened an issue with Microsoft, including a gdb backtrace of the > coredump agaist the python, but I feel this is probably something > fairly straightforward which can be solved by some FreeBSD = configuration > that I am missing somehow. >=20 > github issue is here: >=20 > https://github.com/Azure/WALinuxAgent/issues/1687 >=20 > but I would be intersted to know if anyone has any thoguhts or advice = on > this. Running FreeBSD in Azure is something which has worked well for = me > so far... Does it crash if you run it from the command line with 'env -i' in = front? That clears out the environment and will be a lot closer to the rc.d = environment. If that doesn't show anything then you will have to try capturing stderr = from the rc.d run as that will hopefully have the reason why Python is = aborting (ie what Py_FatalError is complaining about). -- 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?872D68EE-143D-41F3-BC22-45AC4F7E934F>