I own many Raspberry Pi’s and for some reason the PiAware Pi seems to have the most trouble. I even replaced the hardware thinking the hardware was dying on me, but I’m getting the same results on a B+ model.
The only thing I can think of is dump1090 (or something with the FA code) causes the Pi to run out of memory after a while of usage. I think my max uninterrupted FA feed time is 2 weeks, after that I get a notice that my feeder is offline, but when I check on my Pi, it’s online and connected to the internet. Running “sudo service dump1090 restart” and “sudo service piaware restart” works to get it online, but I don’t want to have to do that every few days when I get a notice.
I’ve found that nightly reboots help keep my FA feeds going strong since it resets everything automatically.
Here’s how I set it up in case someone else wants to set it up:
1. Log in as the Pi user
2. Run: sudo crontab -u root -e
3. At the very end, paste in: 0 0 * * * /sbin/shutdown -r now
4. CTRL+O to save, and CTRL+X to quit
That’s it! There’s a few other ways to make it reboot at night (for example, using @daily instead of 0 0 * * *, and /sbin/reboot instead of /sbin/shutdown), but what I have posted above is what is working for me.
Hope this helps anyone looking to do the same thing.
I’m doing the same this as well. I had a couple of lock ups when I first started with the Pi. Is your Pi running on local or UTC time? Mine’s on UTC, so I have it reboot at 0900, which works out to 0400 EST.
FWIW, as a matter of good housekeeping, I routinely use 'sudo shutdown -rF ’ to do a filesystem check on reboot. Takes a few seconds longer but keeps it clean.
YMMV
I have implemented nightly reboots as outlined in this very helpful thread – HOPING it would eliminate the [increasingly frequent] lockups I am suffering since updating to PiAware 1.18. My system runs fine EXCEPT for lockups that occur at no particular time – happens once every day or so even after putting in the nightly shutdown and restart. In fact, my system is down now – 14:25 PST on 8 Dec. When i get home tonight, i will power cycle it and it will most likely come up just fine and run till the next lockup. During lockups, i cannot SSH into the Pi (obviously). Only outward physical sign of trouble is the blue light on my wireless network adaptor is dark (it flashes blue when the system is running).
I am running the PiAware card image, only changes are wireless config, password update, and the nightly shutdown – all else is out of the box!
I’m new to Raspberry Pi/Linux/Dump1090/PiAware – so any suggestions on how/what to troubleshoot are greatly appreciated.
I too saw frequent lockups but these two steps have eliminated them entirely for me. With these steps, there is no real need to reboot nightly since the pi will now reboot only when there is a problem. However, it might still be a good idea to reboot during periods of low activity if it might ward off reboots during high activity.
Just a thought, reboot drops the log files in /tmp. If they might be of interest, one might consider altering the script to relocate them to more permanent lodgings if your Pi has enough room. This won’t work if piaware’s 0-dark-zulu switch for piaware.out.yesterday is hardcoded. I don’t see the loss of the log as a problem for me, YMMV.
No problems with 1.18 or dump1090 (sorry don’t know the dimp1090 vn - it’s about a month old) running continuous.
I suspect you might have a power issue, if you have another supply you could swap over to - see if it changes things.
I’ve wondered about running off one of those power banks you see ebay/amazon - have it running the Pi at the same time as it’s on continuous charge (of course there might be a logical switch to prevent doing that)
You can start piaware with -debug (which disables piaware’s own logging and just emits to stderr/stdout), then redirect-append the output to a logfile of your choice. A logrotate config with “copytruncate” will work with that.
If you copy the file, it is probably a good idea to rename it based on the present time. That way you have a timestamp of when the pi went down and multiple reboots will not cause the file to be overwritten.
I am running PiAware 3.5.3 via the SD card image install and I have to agree with the nightly reboots. I set mine to 0400 local time. My only changes are for my wireless setup.
I saw consistently dropping responses possibly due to memory issues. The reboots have leveled out the traffic I see. I am using class 10 SD cards. Hope this may help anyone having issues. As with all systems, your mileage may vary.
I found the following helpful advice from the LEDE/OpenWRT folks when it comes to scheduling a reboot of a device that has no real-time clock (like the Pi):
# Reboot at 4:30am every Sunday
# Note: To avoid infinite reboot loop, wait 70 seconds
# and touch a file in /etc so clock will be set
# properly to 4:31 on reboot before cron starts.
30 4 * * 0 sleep 70 && touch /etc/banner && reboot
The need for reboots by some is offset by others who have devices that are running the same 3.5.3 for days or longer without a similar need. The Pi3s I have feed FA (3.5.3) and Planefinder, and have been chugging away for several weeks without issue for me so far. I wound up throwing away a Pi2 that was unstable no matter what was running, even a newly-installed OS, different SD cards - that one DID exhibit the “needing reboot before it crashes again, often” syndrome.
So, I would suggest finding out what is the condition of the Pi when it approaches lock up, requiring a reboot - is it overloaded (high CPU temperature)? Is there anything in the kernel logs that indicates problems with applications? Or does it just lock up with no evidence to be found ? If last item - can you revert to an older, working version of the application and have the device NOT lock up/need reboot?
Class 10 is the speed of an sd card, I do not think it matters that much in this case
More important is whether it is branded or a cheaper no name product, how long it is in use under which conditions (heat, cold).
If other issues lead to freezing the pi so you have to reboot, those might in the end also lead to corrupted data or even permantly damaged cells on the card.
