Cumulus Support

I stop CMX overnight and do a backup to NAS and then restart all via a cron job.

Apart from that I leave the Raspberry Pi running 24/7 unless a reboot is needed after a software upgrade.

Thinking about such things as memory leaks from Mono would a scheduled reboot be of any be of any benefit?

if so daily/weekly/monthly?

I am running CMX on Pi with Ecowitt station, and at least on my system the leaked memory (overgrowth of mono process) is freed properly by just stopping CMX. So at least in my case a scheduled reboot is not necessary, if CMX is restarted regularly.

Being said that, it is possible that other station types trigger different kinds of memory leaks, so if one wants to be sure how their own installation behaves, just run command ”free” before and after stopping CMX, and you see if the memory is freed properly.

As above just stopping Cumulus terminates mono and the memory is freed, I have never needed to reboot my pi to free up memory.

The leak in the WLL station code is now gone, the only other one I know of is in the GW1000 station type. Unfortunately the cause is different, and still unknown.

Ok thanks - as well as a WLL I have a Ecowitt GW1000 and a Ecowitt Wittboy.

Does the same leak affect the latter as well?

Is there any harm to doing a scheduled reboot???

I could just add sudo reboot to the end of my daily bash backup script

The Dalek Hunter wrote: ↑Tue 03 Jan 2023 11:51 am Ok thanks - as well as a WLL I have a Ecowitt GW1000 and a Ecowitt Wittboy.

Does the same leak affect the latter as well?

If you use the GW API station type, yes. If the HTTP station type, then I do not think so.

The Dalek Hunter wrote: ↑Tue 03 Jan 2023 11:51 am Is there any harm to doing a scheduled reboot???

Not as far as CMX is concerned, but daily seems excessive, I have pi's I haven't rebooted for 6 months or more!

Ok - many thanks

mcrossley wrote: ↑Tue 03 Jan 2023 12:52 pm If you use the GW API station type, yes. If the HTTP station type, then I do not think so.

I have to disagree on this based on my own experience. I’m running b3196 on rpi3b+ with mono 6.8 and HTTP station type. I also have rpi4b running b3213 with mono 6.12 and GW API station type. They both are connected to the same gw1100, and both do leak some memory. In 3-4 weeks the mono process grows to 500-600 megabytes on both, but of course it is a bigger problem with the pi3 and 1GB memory than with the Pi4’s 4GB memory.

There seems to be some variance, but I have not been able to pinpoint the reason. Obviously for example if I have to reboot my wifi router for a firmware update, both instances see it differently. For one the data only stops, and the for the other gw1100 seems unresponsive. Maybe this makes a difference, maybe not. Not a big problem for me anyway.

OK thanks, I do not leave any Ecowitt instances running for long - just for testing purposes. It's a pain, the fault does not appear to be in my code as it does not leak on Windows. And the thing that fixed the WLL code was simply changing from using a synchronous .Receive() to the equivalent .ReceiveAsync() for receiving the UDP broadcasts, nothing else really changed. However, the GW1000 and HTTP Ecowitt code is quite different (and both different from each other) so the same fix does not apply there. I have created quite simple small test apps that just do the receiving and discard the data from the stations and nothing else and they leak on Mono as well.

Ok, interesting to hear the background. If the issue with mono is quite easy to repeat with a simple program by just listening to http requests and posting some data to it, maybe it would be worth reporting to mono developers. But if you think it is not worth the effort, that is fine by me also.

As developement suggestion one way of working around this would be a possibility to trigger CMX restart or an alarm when mono process size exceeds some user configured limit. But this might also not be worth the effort.

Or eventually ditch mono and port it to .Net 6 or 7