Re: python dameon coredumps when started from boot, but not by hand
> 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 random guess. A good one, and one which makes me wonder if theres some shared library config which isnt happening and maybe that is it ? Am going to do an experiment to see if the same behaviout occurs on a real hardware machine not in Azure - which might make it easier to debug as I can at least see the console that way. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: python dameon coredumps when started from boot, but not by hand
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 everything apart from mysql data. Just a random guess. A good one, and one which makes me wonder if theres some shared library config which isnt happening and maybe that is it ? Am going to do an experiment to see if the same behaviout occurs on a real hardware machine not in Azure - which might make it easier to debug as I can at least see the console that way. Check "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" Check if ldconfig is runable (I ended up with permissions 0444 on /etc/rc.d/ldconfig after some etcupdate run) Next things - try to run it as: 1) service myservice start or 2) /usr/local/etc/rc.d/myservice start There can be differencies. You can also try to start it from cron instead of hands (different environment) or try to start in on boot from crontab with tag @reboot. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: python dameon coredumps when started from boot, but not by hand
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 etcupdate run) Just checked that and its 777 > Next things - try to run it as: > 1) service myservice start > or > 2) /usr/local/etc/rc.d/myservice start > > There can be differencies. Both of those give the same result - this is in /etc/rc.d not in /usr/local/etc/rc.d, but that wont make a difference I assume ? > You can also try to start it from cron instead of hands (different=20 > environment) or try to start in on boot from crontab with tag @reboot. Those are both interesting ideas. Cant tst them immediately, but will try later today if I can. Thankyou! -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: python dameon coredumps when started from boot, but not by hand
> 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 that would be easier to understand, but python from rc.d, but then it cant run another python iterpretter without it coredumping. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: python dameon coredumps when started from boot, but not by hand
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/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: python dameon coredumps when started from boot, but not by hand
> 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 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. > > Be sure to use the -i flag so children of the traced process also get > traced. I also suggest "-f " 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 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
