Im running a light setup. Stock Raspian image with Mutability and Piaware as an addon (not the SD card image)
It will seem to run ok for 24 hours or so then start crashing. My cpu hangs around 40-50. Everything runs great other than the crashing.
Nothing else on the pi seems affected. I will notice it offline, ssh in and mutability is simply not running any longer
I run it from the “dpkg reconfigure” line
Any logs I could share? Ideas?
Hmmm… If you have access to a good digital voltmeter, measure the + volt rail on the Raspberry Pi. I’d put 50 cents or a cheap beer on the +5 rail measuring 4.7 Volts or less. If things are on the edge, the added load from a few cron jobs going off simultaneously could cause problems.
bob k6rtm
anything interesting in the /var/log/dump1090-mutability.log file?
are you saying your starting the program by running dpkg-reconfigure? That does start the service when it’s all done setting it up. You may want to issue a sudo service dump1090-mutability stop then sudo service dump1090-mutability start just to bounce it, and see if it stabilizes.
Thanks guys. You may be on to something. The syslog log and the timing of my offline times seem to show a reboot that I didn’t know about.
Like I said this is a clean setup. No mods, no scripts. Just raspian,mutablitity, and piaware. You guys are much better at this so tell if this looks right. Also, if its rebooting, which it is, why isnt Mutability starting like it does when I simply SSH in a “sudo reboot”
Mar 18 18:35:41 pi2 ntpd[2198]: peers refreshed
Mar 18 18:35:41 pi2 ntpd[2198]: Listening on routing socket on fd #19 for interface updates
Mar 18 18:35:41 pi2 ntpd[2198]: restrict: error in address ‘::’ on line 38. Ignoring…
Mar 18 18:35:41 pi2 ntpd[2198]: restrict: error in address ‘::1’ on line 42. Ignoring…
Mar 18 19:17:01 pi2 /USR/SBIN/CRON[4439]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 20:17:01 pi2 /USR/SBIN/CRON[7097]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 20:52:22 pi2 shutdown[8555]: shutting down for system reboot
Mar 18 20:52:22 pi2 init: Switching to runlevel: 6
Mar 18 20:52:23 pi2 ifplugd(eth0)[1672]: Exiting.
Mar 18 20:52:23 pi2 ifplugd(wlan0)[1613]: Exiting.
Mar 18 20:52:24 pi2 ifplugd(lo)[1626]: Exiting.
Mar 18 20:52:24 pi2 ntpd[2198]: ntpd exiting on signal 15
Mar 18 20:52:42 pi2 kernel: imklog 5.8.11, log source = /proc/kmsg started.
Mar 18 20:52:42 pi2 rsyslogd: [origin software=“rsyslogd” swVersion=“5.8.11” x-pid=“2085” x-info=“http://www.rsyslog.com”] start
Mar 18 20:52:42 pi2 kernel: 0.000000] Booting Linux on physical CPU 0x0
Mar 18 20:52:42 pi2 kernel: 0.000000] Initializing cgroup subsys cpu
Mar 18 20:52:42 pi2 kernel: 0.000000] Initializing cgroup subsys cpuacct
Mar 18 20:52:42 pi2 kernel: 0.000000] Linux version 3.18.5+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Li$
Mar 18 20:52:42 pi2 kernel: 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
Mar 18 20:52:42 pi2 kernel: 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Mar 18 20:52:42 pi2 kernel: 0.000000] Machine model: Raspberry Pi Model B
Yes from “dpkg-reconfigure” I will try that. Nothing pops out at me in the Mut log file. However in the syslog I see a list of cron jobs followed by a reboot that coincides with the times of the offline times.
Mar 18 06:25:09 pi2 rsyslogd: [origin software=“rsyslogd” swVersion=“5.8.11” x-pid=“2092” x-info=“http://www.rsyslog.com”] rsyslogd was HUPed
Mar 18 07:17:01 pi2 /USR/SBIN/CRON[6330]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 08:17:01 pi2 /USR/SBIN/CRON[9965]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 09:17:01 pi2 /USR/SBIN/CRON[12828]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 10:17:01 pi2 /USR/SBIN/CRON[15861]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 11:17:01 pi2 /USR/SBIN/CRON[18852]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 12:17:01 pi2 /USR/SBIN/CRON[21450]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 13:17:01 pi2 /USR/SBIN/CRON[24183]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 14:17:01 pi2 /USR/SBIN/CRON[26683]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 15:17:01 pi2 /USR/SBIN/CRON[29369]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 16:17:01 pi2 /USR/SBIN/CRON[32093]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 17:17:02 pi2 /USR/SBIN/CRON[2828]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 18:17:01 pi2 /USR/SBIN/CRON[5789]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 18 18:35:18 pi2 shutdown[6744]: shutting down for system reboot
Mar 18 18:35:18 pi2 init: Switching to runlevel: 6
Mar 18 18:35:19 pi2 ifplugd(eth0)[1680]: Exiting.
Mar 18 18:35:19 pi2 ifplugd(wlan0)[1693]: Exiting.
Mar 18 18:35:20 pi2 ifplugd(lo)[1622]: Exiting.
Mar 18 18:35:20 pi2 ntpd[2222]: ntpd exiting on signal 15
Mar 18 18:35:38 pi2 kernel: imklog 5.8.11, log source = /proc/kmsg started.
Mar 18 18:35:38 pi2 rsyslogd: [origin software=“rsyslogd” swVersion=“5.8.11” x-pid=“2077” x-info=“http://www.rsyslog.com”] start
Mar 18 18:35:38 pi2 kernel: 0.000000] Booting Linux on physical CPU 0x0
Mar 18 18:35:38 pi2 kernel: 0.000000] Initializing cgroup subsys cpu
Are you running hardwired or wireless network? I was having problems with my sandbox hanging with wireless. (was actually still alive but the network would drop. Hooked up wired now and no more probs.
Cheers!
LitterBug
I am wireless but it is strictly Muta. that is crashing. I think there is a time frame that is consistent with the crashes. I am far from a comfortable user of linux. The syslog at first seemed to show some correlation with cron jobs but it appears it is not in a specific order. What logs are available that will show a service dropping out? It seems to be in the 4 pm time range and it will do it a few times after that and then run for the rest of the time ok. I will watch today again around that time.
humour me, try a different power supply.
Just thinking it might be a power fluctuation causing the dongle to do something weird, which in turn is upsetting dump1090.
Ill do it.
Just wanted to drop in and say I am experiencing the same issue with dump1090-muta, I was running stock piaware with dump1090 for a month or so without any crashes and ever since switching to dump1090-muta I have had the same kind of crashes you are experiencing.
I haven’t had a chance to check logs yet but I plan on checking them tonight. I’m hoping it’s something that can be easily fixed maybe a weird setting I miss configured or something.
Around 4-6 pm seems to be the “dark” hours for my mutability 
So I hope to compare some logs again once it happens, if it does.
Please let me know what you see.
Would be handy to see the dump1090 logfiles from around the time of the reboot.
I don’t know of any outstanding crash bugs in dump1090-mutability, and certainly something that crashes/reboots the whole Pi should be impossible in theory unless it’s something like memory exhaustion (but that would look different I think) or power problems etc.
It might be the case that dump1090-mutability pushes the dongle + USB a bit harder (higher sample rate) so setups that are a bit marginal might start failing.
I run multiple Pis on dump1090-mutability without problems. I am also a little on the fanatic side for power supplies, but then again I don’t have power supply issues…
bob k6rtm
I’m running a plain old PiB with Dump1090-mutability - reporting 300,000 positions / 3200 aircraft a day - no problems with reliability, it just works and works
Now Mutability does do more work that Malcolm Robs dump1090 with higher sample rates, etc trying to squeeze more aircraft out of that signal.
I doubt if it’s a specific software issue, may be something external - power, is it running hot (the main reason I wouldn’t suggest putting the pi in the attic), etc.
Ive read some time ago about power issues but have never experienced it myself. I have ran two audio feeds (darkice/icecast) through a powered hub with my Pi in the past using two usb soundcards. I am going to try something similar with my adsb setup. I am powering the Pi with the hub and have the dongle in the hub also. We will see if I have better luck. How many amp power supply do you recommend for the Pi?
Thank you all for your input. I think its great how active this forum is.
When I got my first Pi B I used a Kindle power adapter and it wouldn’t run right. Sometimes it would boot and sometimes not. I got a 2 amp power adapter and it’s been fine since.
l have been using a RPi B+ for a month, it never crashed.
A week ago I got my 2nd RPi which is Model2, and since then I am facing problem: the dump1090-mutability frequently & silently dying (heart strokes? ). I discovered this only when I checked my stats on flightaware, and found receiver alive, but number of planes zero for many hours.
I check dump1090-mutability by command “sudo /etc/init.d/dump1090-mutability status” and got responce "…] dump1090-mutability is not running .[F failed! "
I then restarted dump1090-mutability by command “sudo /etc/init.d/dump1090-mutability start”, then again checked status by command “sudo /etc/init.d/dump1090-mutability status”, it showed “[ ok ] dump1090-mutability is running.”
This scenario keeps on repeating every few hours 
I am using a 3000mA switching type power supply exclusively for RPi Model2.
Can you check the dump1090-mutability logfile (defaults to /var/log/dump1090-mutability.log) to see if anything was logged when it died?
Here is the log file: http://1drv.ms/18Rd5UQ
Edit: The Log was too long when posted here directly. I have now removed Log text from the post, and given above a link to the log file.
If those times correspond to when you are seeing unexpected failures, there is something else on your system (piaware?) that is explicitly killing dump1090.
piaware will log if it’s messing with dump1090 - check the piaware logs.
(If they don’t correspond to unexpected failures, can you tell me what time was an unexpected failure?)