On 10/Nov/2019 22:20, Kevin P. Neal wrote:
The rc script must have a function that starts the python program, right?
Actually, no. It just looks like this:
#!/bin/sh
# PROVIDE: waagent
# REQUIRE: sshd netif dhclient
# KEYWORD: nojail
. /etc/rc.subr
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 suggest
> On 5 Nov 2019, at 01:45, Kevin P. Neal wrote:
>
> On Mon, Nov 04, 2019 at 02:50:14PM +, 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
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!
-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
> Ah, does python get run before the ldconfig service runs?
Nope, this is comming way after ldconfig has run - also the first python
interpretter runs fine, is the one which that python script then tries to
launch which fails.
Thats the bit which really puzzles me - if it was python dying then
th
Thanks for the ideas, running through these in order...
> Check "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*"
So, its running directly after sshd and before swaplate and the
local stuff.
> Check if ldconfig is runable (I ended up with permissions 0444 on=20
> /etc/rc.d/ldconfig after some etcupdat
Pete French wrote on 11/04/2019 13:30:
Shot in the dark: Is it possible that python is trying to dynamically
load a shared library that isn't available yet due to being on a not-yet
mounted filesystem?
I wondered about that, but I have these boxes confiured with only one filesystem
for everythi
> Shot in the dark: Is it possible that python is trying to dynamically
> load a shared library that isn't available yet due to being on a not-yet
> mounted filesystem?
I wondered about that, but I have these boxes confiured with only one filesystem
for everything apart from mysql data.
> Just a
> On 1 Nov 2019, at 23:26, Pete French wrote:
>
>> Hmm, does changing the command_args line to this work:
>> command_args=3D"start 2>/tmp/waagent.log"
>> work?
>
> That is byte-for-byte identical to what I tried :-) It creates the file
> in /tmp, but the file remains empty.
Oops, sorry :)
>
> Hmm, does changing the command_args line to this work:
> command_args=3D"start 2>/tmp/waagent.log"
> work?
That is byte-for-byte identical to what I tried :-) It creates the file
in /tmp, but the file remains empty.
I think I need to look at the source code to work out whats up with it (on
the
> On 1 Nov 2019, at 01:28, Pete French wrote:
>
>> Hmm very odd..
>> Does the tool depend on something else running?
>
> No, not at all. Earlier versions of the tool dont do this either.
>
> On a machine running the tool started by hand the two processes look like
> this:
>
> 0 86918
> Hmm very odd..
> Does the tool depend on something else running?
No, not at all. Earlier versions of the tool dont do this either.
On a machine running the tool started by hand the two processes look like this:
0 86918 1 0 20 03426823860 wait I 0- 0:00.92
python
> On 31 Oct 2019, at 20:49, Pete French wrote:
>
>> 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.
>
> Interesting idea, but no, that works fine. Annoyingly!
Hmm very odd..
> 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.
Interesting idea, but no, that works fine. Annoyingly!
> If that doesn't show anything then you will have to try capturing stderr
>
> On 31 Oct 2019, at 10:09, Pete French 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.
>
> gi
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 co
16 matches
Mail list logo
