Alright, here are the final few lines:
fi
if grep -q 'START_DUMP1090="yes"' /etc/default/dump1090-mutability ; then
sed -i 's/START_DUMP1090="yes"/START_DUMP1090="no"/g' /etc/default/dump1090-mutability
systemctl stop dump1090-mutability || true
fi
OK, these are the bottom 4 lines of code in your file. Above and below this block of code, you have to add new line of code.
(1) Below last line ( which is only fi) add another line which is also only fi
(2) Counting from bottom, bove 4th line, add this line
if grep -q "^receiver.*dvbt" /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then
With above modification, bottom 4 line block of code will become bottom 6 line block of code as follows:
if grep -q "^receiver.*dvbt" /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then
if grep -q 'START_DUMP1090="yes"' /etc/default/dump1090-mutability ; then
sed -i 's/START_DUMP1090="yes"/START_DUMP1090="no"/g' /etc/default/dump1090-mutability
systemctl stop dump1090-mutability || true
fi
fi
A few days before the latest FR24 update push, I took a look at the fr24 logs. Despite my config being set to rotate logs, a single, large and ever-growing file existed. The date/time of log shows this started after re-imaging my SD card to PiAware 7.1 and re-installing fr24feed. If you have done the same recently, you may want to check on this to make sure you are not similarly afflicted. Sorry I canât provide a root cause or fix. FR24 was a secondary, kind of eye-candy thing for me. I solved my problems with a âsudo apt purge fr24feedâ.
Fix is very easy. Edit file /etc/fr24feed.ini and change logmode="1" or logmode="2" to logmode="0". The logs will stop saving to file.
Logfile mode:
0 - Disabled
1 - 48 hour, 24h rotation
2 - 72 hour, 24h rotation
Please see screenshot of my file /etc/fr24feed.ini
Yes, I did set it to disabled as a test and that did work. But it doesnât solve the problem that the rotation options seem to not work as advertised. Anyway, it is moot to me as Iâve decided not to feed FR24 anymore.
FR24 does not add their log file into the rotatelogs facility. I simply added it and it now rotates properly. create a txt file /etc/logrotate.d/fr24feed and in this file put:
/var/log/fr24feed/*.log {
daily
missingok
rotate 10
compress
delaycompress
copytruncate
notifempty
postrotate
if
/bin/systemctl status fr24feed.service > /dev/null ; then
/bin/systemctl restart fr24feed.service > /dev/null;
fi;
endscript
}
So, the feeder that stopped working last week has been working well with wiedehopf scripts (tar1090 / graphs1090). After a few days I also rebuilt my other feeder to get it to the same level. That worked fine for a few days, but this morning I woke to a email from Flightaware that it had stopped sending. The pi was still up, and the tar1090 page on it was working and showed planes. I didnât have much time before I left the house, but I did quickly SSH onto it, and ran piaware-status, and all seemed to be running ok, but I did have the line that it wasnât feeding to Flightaware (hence why I got the email). I just did a reboot, and when it came up all was working ok again.
Are there any logs I can check to see why / what may have happened, or did anyone else get an outage last night. Wondering if for some reason there was a network blip, and it stopped sending, but a) not sure if it should have just restarted, and b) the other feeder was ok.
/var/log/piaware.log
Thanks, but that doesnât exist for me. I used a base PI OS install, then wiedehopf scripts, and then his instructions to install the Flightaware feeder.
So did I and I have a piaware log file in /var/logs on my Pi.
If you have piaware installed as Debian Package on top of a running Raspberry OS or Ubuntu, you will have a log file in /var/log.
Very strange, that file is not there on either of my feeders.
If you followed the guide completely, you wouldnât have that log as it removes rsyslog to avoid sd-card writes.
Youâd have to check journalctl (reboots will eliminate that log)
sudo journalctl -u piaware -e
Yep, I did run the command to remove rsyslog.
Ok, so if it happens again I will check journalctl before I reboot.
I was going to follow a guide to get the OS / system running from an attached SSD (I did have one of my feeders working like that before I did the rebuilds). Assume if I do that I could re-enable rsyslog.
Itâs not so bad ⊠just reinstall it.
sudo apt install rsyslog
So, it crashed out again today. Just got the âdownâ email.
did âsudo journalctl -u piaware -eâ and the last few line of the output show:
Feb 10 08:50:39 raspberrypi piaware[745]: mlat-client(818): Server status: synchronized with 724 nearby receivers
Feb 10 08:50:39 raspberrypi piaware[745]: mlat-client(818): Receiver: 1487.5 msg/s received 252.7 msg/s processed (17%)
Feb 10 08:50:39 raspberrypi piaware[745]: mlat-client(818): Server: 0.1 kB/s from server 0.0kB/s TCP to server 3.2kB/s UDP to server
Feb 10 08:50:39 raspberrypi piaware[745]: mlat-client(818): Results: 62.7 positions/minute
Feb 10 08:50:39 raspberrypi piaware[745]: mlat-client(818): Aircraft: 16 of 27 Mode S, 79 of 95 ADS-B used
Feb 10 08:54:39 raspberrypi piaware[745]: 1841565 msgs recvâd from readsb (3357 in last 5m); 1841565 msgs sent to FlightAware
Feb 10 08:59:39 raspberrypi piaware[745]: 1844825 msgs recvâd from readsb (3260 in last 5m); 1844825 msgs sent to FlightAware
Feb 10 09:04:39 raspberrypi piaware[745]: 1848299 msgs recvâd from readsb (3474 in last 5m); 1848299 msgs sent to FlightAware
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Receiver status: connected
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Server status: synchronized with 725 nearby receivers
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Receiver: 1560.0 msg/s received 248.1 msg/s processed (16%)
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Server: 0.2 kB/s from server 0.0kB/s TCP to server 3.1kB/s UDP to server
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Results: 75.4 positions/minute
Feb 10 09:05:39 raspberrypi piaware[745]: mlat-client(818): Aircraft: 16 of 31 Mode S, 82 of 100 ADS-B used
Feb 10 09:09:39 raspberrypi piaware[745]: 1851856 msgs recvâd from readsb (3557 in last 5m); 1851856 msgs sent to FlightAware
Feb 10 09:12:30 raspberrypi piaware[745]: Lost connection to adept server at piaware.flightaware.com/1200: server closed connection
So, nothing much to go on really, just that at 9:12:30 it âLost connectionâ. Not sure why, internet was up / ok at that time, and the other feeder was ok.
I wonder if this is the tcl-tls hang again.
Whatâs the version of tcl-tls you have installed? (dpkg -l tcl-tls)
If you can catch it in the act, is the piaware process still running, and is it taking lots of CPU?
It seems to be 1.7.22-2 (on both my feeders).
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
++±==============-============-============-=================================
ii tcl-tls:armhf 1.7.22-2 armhf TLS OpenSSL extension to Tcl
To add, looking at my FlightAware stats it seems the first âcrashâ was about 3 days 5 hours after I rebuilt the feeder, and then the next crash was about 3 days 3 hours. Will see what happens in 3 days time!!!
So, after being ok for just over a month, just got the email to say itâs stopped feeding.
SSHâed into server, and did TOP, this is what was shown:
So yes, piaware still running, and using 100%.
I see version 7.2 is out (think I built this with 7.1), so may be worth updating.
Update Noticed my other feeder was also not feeding, looking at the time they both went off just after 2pm today, and then I remembered that I was re-configuring by router about that time, and as it was rebooted several times there would have been no Internet connection, so that may have caused it.