reef-pi :: An opensource reef tank controller based on Raspberry Pi.

[That Crusso Kid]

I threw this together last night since I had an out of memory issue, I assume restarting the reef-pi service would reset the memory usage. It still needs some cleanup and some additional error checking to verify that the service started up. The basic idea is you drop this in cron.daily (/etc/cron.daily) which is executed at 3am your local time, if the available free memory is less than 150M then it will restart the reef-pi service. Outputs to a file in your directory the information for the free command and also if it restarts the service. Update the file with your path to your home directory.

#!/bin/bash
/bin/date > /home/bishop/pi-memory.txt
/usr/bin/free >> /home/bishop/pi-memory.txt
freemem=`/usr/bin/awk '{print $7}' /home/bishop/pi-memory.txt`
if  (( $freemem < 150000 ))
then
    /bin/echo $freemem >> /home/bishop/pi-memory.txt
    /bin/echo "restarting reef-pi" >> /home/bishop/pi-memory.txt
    /bin/systemctl restart reef-pi.service
else
   /bin/echo "not less that 150M" >> /home/bishop/pi-memory.txt
fi

If anyone has any questions or something that would work better just let me know, just wanted something to check things overnight and reset if necessary, no warranties as usual ;)

Saaay whaaaaat? No warranty! Or you could just go the route of what so many manufacturers/suppliers appear to be going in this hobby; offer a warranty that's useless. There's nothing wrong with our product but, rather, it's the way you used it or didn't use it or maintained it or didn't maintain it or looked at it funny... ;);)

Thanks for providing all the help you have been providing lately!

 

[bishoptf]

Saaay whaaaaat? No warranty! Or you could just go the route of what so many manufacturers/suppliers appear to be going in this hobby; offer a warranty that's useless. There's nothing wrong with our product but, rather, it's the way you used it or didn't use it or maintained it or didn't maintain it or looked at it funny... ;);)

Thanks for providing all the help you have been providing lately!

Yeah unfortunately we live in a pretty litigious society these days, like the warnings on lawn mowers to not place your hands or feet under the mower when its running or use it as a hedge trimmer....:)

 

[16Reefer170]

I for one LOVE my little reef-pi. It is perfect, and I thank all of you who make this project possible! ( no warranty and all). I appreciate all the effort you have put into the software, and build guides.

 

[DirtDiggler2823]

Been ramping up, but no unload this time. The CPU and memory readings, are those percentages?

 

[Ranjib]

I threw this together last night since I had an out of memory issue, I assume restarting the reef-pi service would reset the memory usage. It still needs some cleanup and some additional error checking to verify that the service started up. The basic idea is you drop this in cron.daily (/etc/cron.daily) which is executed at 3am your local time, if the available free memory is less than 150M then it will restart the reef-pi service. Outputs to a file in your directory the information for the free command and also if it restarts the service. Update the file with your path to your home directory.

#!/bin/bash
/bin/date > /home/bishop/pi-memory.txt
/usr/bin/free >> /home/bishop/pi-memory.txt
freemem=`/usr/bin/awk '{print $7}' /home/bishop/pi-memory.txt`
if  (( $freemem < 150000 ))
then
    /bin/echo $freemem >> /home/bishop/pi-memory.txt
    /bin/echo "restarting reef-pi" >> /home/bishop/pi-memory.txt
    /bin/systemctl restart reef-pi.service
else
   /bin/echo "not less that 150M" >> /home/bishop/pi-memory.txt
fi

If anyone has any questions or something that would work better just let me know, just wanted something to check things overnight and reset if necessary, no warranties as usual ;)

this is not normal, or we should not be treating this normal. if reef-pi is being oomed (out of memory - killed) then its a serious bug and should be fixed asap. From your last stack trace what I could detect is theres vcgencmd command thats not been able to fork due to out of memory. That command is used to get cpu temperature. We used to show this data (cpu temperature) in past versions of reef-pi, i removed it from ui in 2.0. its still available via /api/info (which is the summary section in reef-pi). I could just remove the code and call it a day, but i think theres something else thats causing this effect.
Anyway, in case reef-pi is out of memory and get killed , systemd will restart reef-pi automatically, this is configured during install:
https://github.com/reef-pi/reef-pi/blob/master/build/reef-pi.service#L7
i have tried to reproduce this , but not been able to. If anyone else experiencing this, do let me know. Stability/reliability are of utmost importance to this project. I have happy to stop new feature work to get those gaps addressed to our desired level.
I'll keep a watch on this. Remember if this is happening, reef-pi will be automatically restarted , and you should see a different uptime (running since ... information in the summary section) in your reef-pi UI

 

[Ranjib]

Been ramping up, but no unload this time. The CPU and memory readings, are those percentages?

CPU is percentage , memory is in MB.

 

[Ranjib]

I for one LOVE my little reef-pi. It is perfect, and I thank all of you who make this project possible! ( no warranty and all). I appreciate all the effort you have put into the software, and build guides.

Thank you. The community is great. I myself learn everyday something new .

 

[bishoptf]

this is not normal, or we should not be treating this normal. if reef-pi is being oomed (out of memory - killed) then its a serious bug and should be fixed asap. From your last stack trace what I could detect is theres vcgencmd command thats not been able to fork due to out of memory. That command is used to get cpu temperature. We used to show this data (cpu temperature) in past versions of reef-pi, i removed it from ui in 2.0. its still available via /api/info (which is the summary section in reef-pi). I could just remove the code and call it a day, but i think theres something else thats causing this effect.
Anyway, in case reef-pi is out of memory and get killed , systemd will restart reef-pi automatically, this is configured during install:
https://github.com/reef-pi/reef-pi/blob/master/build/reef-pi.service#L7
i have tried to reproduce this , but not been able to. If anyone else experiencing this, do let me know. Stability/reliability are of utmost importance to this project. I have happy to stop new feature work to get those gaps addressed to our desired level.
I'll keep a watch on this. Remember if this is happening, reef-pi will be automatically restarted , and you should see a different uptime (running since ... information in the summary section) in your reef-pi UI

Understand, that is what it did, restarted the reef-pi service but started fresh with the stats, I thought that the stats were written to the database and would just be reloaded. Is that the intent when reef-pi service restarts, I've not played with it enough to have a baseline to know the correct answer. I checked one of my other boxes thats on UPS, its running Centos with some vm's for various stuff, here is the uptime on it:

bishop@f15eagle ~]$ uptime
22:35:43 up 547 days, 7:15, 1 user, load average: 0.42, 0.32, 0.33

Once things are dialed in for reef-pi it should be able to run for a long time. :)

 

[dmolavi]

this is not normal, or we should not be treating this normal. if reef-pi is being oomed (out of memory - killed) then its a serious bug and should be fixed asap. From your last stack trace what I could detect is theres vcgencmd command thats not been able to fork due to out of memory. That command is used to get cpu temperature. We used to show this data (cpu temperature) in past versions of reef-pi, i removed it from ui in 2.0. its still available via /api/info (which is the summary section in reef-pi). I could just remove the code and call it a day, but i think theres something else thats causing this effect.
Anyway, in case reef-pi is out of memory and get killed , systemd will restart reef-pi automatically, this is configured during install:
https://github.com/reef-pi/reef-pi/blob/master/build/reef-pi.service#L7
i have tried to reproduce this , but not been able to. If anyone else experiencing this, do let me know. Stability/reliability are of utmost importance to this project. I have happy to stop new feature work to get those gaps addressed to our desired level.
I'll keep a watch on this. Remember if this is happening, reef-pi will be automatically restarted , and you should see a different uptime (running since ... information in the summary section) in your reef-pi UI

Could this be platform dependent, Pi zero vs 3B+?

 

[DirtDiggler2823]

Could this be platform dependent, Pi zero vs 3B+?

I'm not sure about that. Mine is behaving strangely as well. Just got this error while trying to reboot. I noticed my temperature was a bit low, so I tried to do a soft reboot, and that is the error message I received.

 

[b4tn]

Are you guys with memory issues running anything nonstandard or custom code? Non standard as in something different from the build guide? I have not messed with any of the code save for adding the pwm dtoverlay to the config file and installing the updates as they come out. I’m using a pi3 B+ the only thing I’m not running is a ph probe. All the other stuff dosers, lights, and regular functions are all running off one rpi headless. I’m using 3 channels of the pca9685. I seem to be pretty steady on memory and cpu usage.

 

[DirtDiggler2823]

Are you guys with memory issues running anything nonstandard or custom code? Non standard as in something different from the build guide? I have not messed with any of the code save for adding the pwm dtoverlay to the config file and installing the updates as they come out. I’m using a pi3 B+ the only thing I’m not running is a ph probe. All the other stuff dosers, lights, and regular functions are all running off one rpi headless. I’m using 3 channels of the pca9685. I seem to be pretty steady on memory and cpu usage.

Nope. Just running the code that was provided. Not using anything special at all. I'm running a pi3b, so I should have more resources to leverage.

 

[LionHeart2017]

My memory ramps with the timers for my lights from being turned on to off if that helps

 

[dmolavi]

Headless vs non-headless Raspian installs, maybe? I used the "Lite" version - no desktop or UI, just console, from https://www.raspberrypi.org/downloads/raspbian/.

 

[DirtDiggler2823]

Headless vs non-headless Raspian installs, maybe? I used the "Lite" version - no desktop or UI, just console, from https://www.raspberrypi.org/downloads/raspbian/.

I might not be running headless.....

 

[b4tn]

I might not be running headless.....

I used the GUI once to set up my network and never used it again so went ahead and disabled it in raspi-config.

 

[DirtDiggler2823]

I used the GUI once to set up my network and never used it again so went ahead and disabled it in raspi-config.

I might have to do the same once I get home from work

 

[dmolavi]

Also, I don't know what the "recommended software" is which gets installed with the first of those three images on the Pi site. Some of those may contain additional services, etc that eat away at memory over time. I think that the "Lite" version is the best option for our use. Setting up the network via the command line isn't difficult (even if you're not a Linux person). I made some changes to the image so that SSH and WiFi were enabled as soon as it was flashed and boots. I could probably dig those up and post them here for inclusion on the Reef-Pi site...

 

[dmolavi]

Here we go:
1. After you flash the image to the micro-SD card, open the /boot/ partition in your file manager.
2. Enable SSH by placing a file named “ssh” (without any extension) onto the /boot partition of the SD card.
3. In order to connect to a wifi network, create and edit wpa_supplicant.conf (in your /boot partition) and add the following lines:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
ssid="my-network-name"
psk="my-network-pass"
key_mgmt=WPA-PSK
}

Save the file, eject/unmount the micro-SD card and use it to boot up your Pi. From your wireless router, you can find the IP address assigned to "raspberrypi" and do:
ssh pi@<ipaddress>

 

[b4tn]

Here we go:
1. After you flash the image to the micro-SD card, open the /boot/ partition in your file manager.
2. Enable SSH by placing a file named “ssh” (without any extension) onto the /boot partition of the SD card.
3. In order to connect to a wifi network, create and edit wpa_supplicant.conf (in your /boot partition) and add the following lines:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
ssid="my-network-name"
psk="my-network-pass"
key_mgmt=WPA-PSK
}

Save the file, eject/unmount the micro-SD card and use it to boot up your Pi. From your wireless router, you can find the IP address assigned to "raspberrypi" and do:
ssh pi@<ipaddress>

This is useful! I tried to do this via a google search but it didnt work. Looks like I missed a few steps.