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

So heres an oddity - I have a service which runs under python3. It
works fine if I start it from a terminal as root, but when it is
started at boot the python interpretter itself coredumps.

The program in question is the latest Microsoft 'waagent' form
machines running in Azure. This apparently comes in two
pieces, one which starts up and then attempts to syart the other. It
is the latter part which is failing. The parent process launches fine
and repeatedly tries to launch the child, always coredumping before
it starts running any actial python it seems.

This must, I assume, be down to some dfference in the environment between
running a process from rc at boot and runnign with 'service waagent
start'
as root at the command line. But I dont really have any idea what this
might be. The fact the first one starts but the second doesnt make it even
stranger.

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.

github issue is here:

	https://github.com/Azure/WALinuxAgent/issues/1687

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...

-pete.

> On 31 Oct 2019, at 10:09, Pete French <petefrench at 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.
> 
> github issue is here:
> 
> 	https://github.com/Azure/WALinuxAgent/issues/1687
> 
> 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