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
15 matches
Mail list logo
