Thanks again guys, Coming back to original question, why are things crashing - Nigel catches this in the above post correctly! My own 'memory monitor' script fix/hack should now allow me to avoid the crash issue, but ultimately, I still haven't got to the bottom of the crashing EKOS.
If more swap should be required, astroberry should probably do this at time of install with etcher or however. The basic install using etcher has (I believe?) done all the memory allocation for me so the small swap I'd guess is the default. If it is astroberry doing this, maybe it would look at the size of the µSD and 'smartly' allocate memory? Is it this reason astroberry minimum is 16GB with 32GB recommended? If it allocates 4GB swap on a 16GB card, 7 with OS, then that's not really going to handle lots of imaging time! Again, not a computer guru but happy to dig around in my own time, and from reading around, the use of swap does appear to provoke 'try best to avoid' reactions.
Nigel, sods law, the last test with no drop_cache is still running, which if I was imaging, wouldn't be an issue! (36hrs+ without crash). So much for trying to show the crash on the memory graph! I'm pretty sure the crash is down to this memory thing, so happy that I've at least raised the issue and at the very least, your 1st post also told me you were seeing the same effect on cache and free!
gdb got skipped till now, sorry Nigel. I skipped this as I'd just discovered the drop_cache idea, so gdb will be next. I'll also browse around to see about swap agression.
Anyway, I'll do some more tests and just keep popping results here, but I'd hope (come September/October) when the nights are longer that I can do more imaging and confirm that at least the drop_cache will work, giving me what will be my first full night of imaging (previous sessions I've packed up before bed in the wee hours, or crashes each night when leaving things out overnight)!
Thanks again for comments

Read More...