I reverted back to PiAware 2.1.2, as I found the new 2.1.3 and dump1090 unstable and stopped feeding FA more often than not - as discussed in the PiAware 2.1.3 thread.
Anyway, I’ve been observing something these past couple of days and I was wondering if FA included a command within their software that auto reboots the PiAware or my RPi every night at 20:17 GMT.
I have no cron jobs setup, so it is nothing that I have manually setup myself but when I look at my log. This happens every night at the exact same time.
Then, as you can see, the next feed is 50mins later at 21:07 GMT.
Here’s part of my log:
Prior to rebooting, or whatever it is doing, this is the feed data before
[2015-11-13 20:12 GMT] 31030 msgs recv’d from dump1090 (1286 in last 5m); 31030 msgs sent to FlightAware
pi@piaware ~ $ cat /tmp/piaware.out
11/13/2015 20:17:10 ****************************************************
11/13/2015 20:17:10 piaware version 2.1-2 is running, process ID 1964
11/13/2015 20:17:10 your system info is: Linux piaware 3.18.5-v7+ #225 SMP PREEM PT Fri Jan 30 18:53:55 GMT 2015 armv7l GNU/Linux
11/13/2015 20:17:10 connecting to FlightAware piaware.flightaware.com/1200
11/13/2015 20:17:11 FlightAware server SSL certificate validated
11/13/2015 20:17:11 encrypted session established with FlightAware
11/13/2015 20:17:11 autoUpdate is not set in adept config, looking further…
11/13/2015 20:17:11 autoUpdate in /etc/piaware is enabled, allowing update
11/13/2015 20:17:11 manualUpdate is not set in adept config, looking further…
11/13/2015 20:17:11 manualUpdate in /etc/piaware is enabled, allowing update
11/13/2015 20:17:11 multilateration support enabled (use piaware-config to disab le)
11/13/2015 20:17:11 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
11/13/2015 20:17:11 Starting faup1090: /usr/bin/faup1090 --net-bo-ipaddr localho st --net-bo-port 30005 --lat (Intentionally Omitted) --lon -(Intentionally Omitted)
11/13/2015 20:17:11 Started faup1090 (pid 2193) to connect to dump1090
11/13/2015 20:17:11 logged in to FlightAware as user (Intentionally Omitted)
11/13/2015 20:17:12 piaware received a message from dump1090!
11/13/2015 20:17:12 piaware has successfully sent several msgs to FlightAware!
11/13/2015 21:07:16 65 msgs recv’d from dump1090; 65 msgs sent to FlightAware
But when I look at my stats, no data is missing. Any idea what is happening and why?
There’s nothing built into piaware itself which would do a scheduled restart, but since you have left autoupdates enabled it’s probably a periodic auto-upgrade command coming from the FA side trying to update you to 2.1-3 and then restart piaware. I don’t think that should wipe the logs, though, so there’s something else going on. You will probably need to diagnose this one yourself.
Thanks obj. Yes, I too think this now, as it seems to happen every couple of hours. Last attempt was 14:12GMT. As for the missing log data. As long as I am feeding FA, as the web page stats and web page data stream shows, I’m quite happy to just let it do its thing
Since our last communication, I have done a manual update of the Linux, PiAware and Dump1090 and so, I am back at 2.1-3 for PiA and 1.2-3 for dump1090.
Looks like it tried to auto update again at 20:17 GMT.
The reason for the failure of the Auto Update, is because I have the Web Control Panel set to - Prevent Auto Update, as I wanted to keep the older PiAware ver of 2.1-2 and older dump1090 version, as I found 2.1-3 unstable, as discussed in the other thread - unstable in the sense that it would stop feeding FA intermittently and I ended up creating a cron job to reboot pi every 3hrs.
“uptime” is fine and it doesn’t reboot once attempted update has completed. My Putty screen shows the 50min gap when I use the “cat /tmp/piaware.out” command but on the Web Control Panel, it shows a continuous log with the regular 5min gap between sent data.
Hm. If you have auto updates disabled in the control panel, then the FA side should not be sending you auto-update requests in the first place.
Can you PM me the full piaware logs please?
I can’t match up the times you’ve given with any requests from the FA side.
For example I just see your piaware disconnect (a connection timeout - generally means you are having network problems) at 21:02:49 UTC and then reconnect at 21:05:14; there was no command sent from the FA side. I don’t see a disconnect or an update request (or, well, anything unusual) at 20:17.
Given that I’ve never seen anything like this with other piaware installs I think it has to be something specific to your setup, perhaps a cronjob you have forgotten about or something like that. Also, I can’t see how 2.1-3 could be any different than 2.1-2 in terms of connection stability, so whatever the issue there was, it’s probably not the piaware version.
Please would you kindly provide the command for creating a Full Log? As I have gone into Super User mode and from the log directory /var/log, I cannot see a PiAware log.
Update 1532GMT - I just found this, if this is the culprit.
root@piaware:/etc# cat /etc/piaware
set imageType piaware
set autoUpdate 1
set manualUpdate 1
root@piaware:/etc#
I can’t match up the times you’ve given with any requests from the FA side.
For example I just see your piaware disconnect (a connection timeout - generally means you are having network problems) at 21:02:49 UTC and then reconnect at 21:05:14; there was no command sent from the FA side. I don’t see a disconnect or an update request (or, well, anything unusual) at 20:17.
Yes, there is a timeout every 3hrs for 5mins - Thus, 00,03,06,09,12,15,18,21GMT but this is not in a Cron Job, it is on a digital plugin timer. I have done this, so that my Pi2 and dongle can have a 5min rest and then reboot. I used to let it run for 24hrs without a break but got annoyed about receiving “not feeding FA” email alerts quite often.
Given that I’ve never seen anything like this with other piaware installs I think it has to be something specific to your setup, perhaps a cronjob you have forgotten about or something like that. Also, I can’t see how 2.1-3 could be any different than 2.1-2 in terms of connection stability, so whatever the issue there was, it’s probably not the piaware version.
The only cron job I have setup, is restarting of another non-FA feeder. There are no other cron jobs, either in Root or Regular mode.
What does this digital timer do? Cut the power? That’s, uh, not a great idea.
Yes, the timer cuts the power to my Pi for 5 mins, then boots up a fresh feed. Why not a good idea? I used to have a cronjob that rebooted the Pi every 3hrs, just using the basic command “sudo reboot”.
Yeah, a graceful shutdown is a better idea. But why are you restarting it every 3 hours anyway??
(I rebooted my original Pi B today to test a new sdcard image on older hardware. It had been up without a reboot for 291 days before that)
Sorry for delay in replying: - Time Zone + Sleep + Work
Atari400 - A straight power cut does not allow for a graceful shutdown and so you might end up with corruption.
Good point, as I don’t shutdown my pc or laptop that way and a RPi is a computer too I guess
obj - Yeah, a graceful shutdown is a better idea. But why are you restarting it every 3 hours anyway??
(I rebooted my original Pi B today to test a new sdcard image on older hardware. It had been up without a reboot for 291 days before that)
I was thinking of creating a cron job with a KILL ALL command or separate “sudo service stop” lines and then rebooting my Pi and the reason for every 3hrs, is that I’ve had it setup like that through our summer and even though the USB Dongle is outside in a protected waterproof and ventilated cover, it was still over-heating to the point it would stop receiving. But now it’s getting towards Winter and the Dongle isn’t getting so warm. I will do as your other message says - Get rid of the timer and format a new image onto my sdcard and leave it for a week. I might even put a wager on it saying that it won’t last 12hrs before I have to reboot it but that’s no good when I am in bed or at work and I cannot access it remotely to reboot.
I even created a cron job with a PING to router, so that if it receives a “0” from my router (ntwrk issue) then the Pi reboots itself but I don’t think that worked very well lol.
If it is overheating, then you should investigate improving the cooling rather than unconditionally rebooting it all the time. Add a fan and more ventilation holes onto a protected side of your waterproof housing, and add heatsinks onto the chips of the Raspberry Pi.
Hi bovineone, my Pi2 doesn’t overheat. So, not sure whether to add heat sinks to it. As for the Dongle - it is close to the antenna which is on a 9 meter mast above my roof. So, it will get direct sunlight hitting the protective casing it is in and thus, causing it to get too warm. Except for adding a fan etc, the only other way, is to extend the coax from antenna to Dongle and strapping the Dongle to my aluminium poles, facing my external wall without any protective casing, so that it gets all the air it needs and will be protected from the Sun and rain.
obj Just currently writing a new image to my sdcard - hence my current outage if you’re looking at my feed
update 2200hrs GMT: Now running a fresh image without plug-in timer. Will try and keep this running continuously for 24hrs.
I have ran the fresh install for the past couple of days and due to the gale force winds we have had here over the last few days, it appears that the wind is somehow blowing my telephone/internet line to the point of it losing my internet connection and whilst the internet comes back on straight away, the Pi loses sync with my router.
Therefore, I have no alternative but to create a sudo reboot cron job every few hours to maintain my Pi connection.
I have tried a PING to router cron job but that doesn’t seem to work. This is the command I use:
*/6 * * * * ping -c 1 000.000.0.0 &> /dev/null && echo success || sudo reboot
Naturally, I have substituted my IP addy for zero’s.
Meaning that when my internet disconnects and reconnects from my ISP due to weather. Only my Pi2 doesn’t reconnect and I have to reboot my Pi to get the connection back.
I do not know why it does it and I do not know how to solve the problem, other than rebooting my Pi.
I am unable to reboot my Pi from the FA Control Panel, obviously due to loss of connection but I am able to reboot the Pi from my Putty screen. So, the problem isn’t within my Home Network, it must be from my router to my ISP’s server/modem racks or whatever they use.
I’m going to try a different PING routine. Instead of PINGing my router which will obviously give an echo success, as it’s within my Home Network. I’m going to try a domain server such as google, as that will have to use my ISP server for access: Thus;
Ok, so you can still access the Pi via ssh, and it can reach your router, but it does not reestablish the connection to the FA servers?
What do the piaware logs (in /tmp/piaware.out) say when it is in this state? They should give you more detail about the failure. It might be a piaware bug, but for the bug to be identified I do need to know what is happening in detail.
I have setup cron job for RPi to reboot every hour when I found dump1090-mutability crashes frequently without showing any reason in logs.
I had discussions with Oliver (obj) in thread “Crashing for Some Reason”, but the cause was not found.
After couple of months I changed the existing antenna by my newly designed antenna. As usual, after changing the antenna I tested the electrical continuity between dvb-t dongle & new antenna. I found one of the connectors in the coax was doggy, giving intermittent connection between antenna & dvb-t. I replaced the doggy connector by a new one and started the system. I noted that dump1090-mutability’s silent deaths have stopped. I put back the old antenna, and still no silent deaths of dump1090-mutability. This confirmed that it was due to doggy connector. Whenever connection was broken (by vibrations or wind), the dump1090-mutability’s cpu usage shot up, and after short while it died. When the doggy connection re-established, dump1090 wont restart unless I restart it manually or reboot the RPi.
I then removed the cron job of rebooting RPi every hour.
