Read the statement by Michael Teeuw here.
RPI3 running out of memory
-
@gschmall
Most probably a 3rd party module is responsible.
I would try disabling the most recent one (or more than one) and try to find out which is responsible.
There have been more cases of this in the past.
You should find them here in the forum. -
I have a few standard modules installed and ONE 3rd party module. Mine locks up -all the time- and I can not figure out why. The 3rd party module is one that the author runs in his own environment with a setup just like mine and never has an issue.
I’ve been chasing the issue with zero progress for weeks and weeks.
-
I have a schedule set up that reboots my pi on a regular basis. You could easily do the same and bounce it at 2 AM or whatever.
-
Once-a-day reboots don’t generally help much with random lock-ups. I wrote a script that checks the error log for “out of memory”. If the string is found, it shuts down the mirror, flushes the logs, starts the mirror back up, and sends me a push notification so I know of the error. I run the script via cron every five minutes and get anywhere from 2 to 20 events per day with no rhyme or reason to it.
Also, my mirror shuts down each day at 11PM and boots up at 7AM. So, it’s only running for 16 out of 24 hours every day.
-
@ember1205 Hrm. In that case, I would try disabling a module for 24 hours and see if your notifications change frequency. Narrow the problem down. If none of the modules are the culprit, let us know and we’ll try to come up with other ideas.
-
That would seem a reasonable approach, but all you can definitively determine is that a specific module is not the sole culprit if the error persists.
-
Disable module, error doesn’t return in 24 hours. This does not definitively prove anything as it might be a still-enabled module that causes the fault but only because some other module or setting is creating the condition where the fault occurs.
-
Disable module, error returns. This does not definitively prove anything except that the disabled module is not the sole reason for the fault. It could be creating “some” of the faults or be related to the fault occurring.
In other words, this is essentially the situation of it being impossible to prove a negative.
I use ImagesPhotos and have issues with my RPi3 faulting. I also use the default CurrentWeather, WeatherForecast, and GoogleCalendar modules.
-
-
Maybe there be a chance of your RAM(or related system whatever) might be defective or inferior, unfortunately.
-
@ember1205 - It’s still useful information, even if it is the combination of two modules. Remove one module and the problem dissipates. In the end, it doesn’t really matter if it is one module or a combination of two modules that causes the memory error. It gives you a path forward without errors.
-
Worth considering increasing your swap file size while you try to determine the cause. That will start using file system space as memory.
Change
CONF_SWAPSIZE=100to#CONF_SWAPSIZE=100in/etc/dphys-swapfileand reboot.Then you can check on the swap size used, and see if it’s a memory leak that just keeps on growing, or something else.
-
I think you’re missing the point.
If you have two modules, X and Y, and you disable one and the problem persists? What’s your diagnosis?
How long do you allow the system to run with one module disabled and no fault before you are able to actually, definitively, able to declare that the problem is the sole result of that module?
Even if you can declare the issue gone, how do you know that it wasn’t an issue related to the combination of modules?
Without explicit logging and debug information to actually see a stack trace of the fault, there is no way to declare “anything” by disabling a module.
