System Monitoring

Nice. I guess with that OS you need to hook the Pi to a screen to setup Ubuntu at first? Then after you can SSH into it.

Thanks for the information everyone. I have been tied up at work trying to launch a new web site for a client and dealing with another that does not wanting to play nice with FedEx… I should be able to look into your responses tonight at the latest.

Thanks again!

No, Screen & keyboard are not required to setup Ubuntu_Vivid_Mate on Orange PI. the SSH is activated by default, just power up the newly burned image, and wait for some time for it to boot fully, then SSH. However unlike Raspbian, the Desktop is also activated by default, and available for screen through HDMI.

The reason I used TV for yesterday’s install of Ubuntu is that yesterday before trying Ubuntu, I have tried openElec which has kodi/xbmc media center embeded. I had to hookup OPi to TV through HDMI to check openElec’s performance for video & audio. This hookup was already in place when I tested my very first install of Ubuntu_Vivid_Mate. Immediately after first boot of Ubuntu, I checked from windows desktop, and found SSH was activated by default. Since I have already hooked up TV, mouse & keyboard, I used Terminal of Ubuntu_Vivid_Mate for all commands to setup Ubuntu, create user “pi”, install dump1090-mutability, rrdtools/collectd and data feeders. I installed everything manually this time.

Today’s both installs were without OPi hooked to TV, keyboard & mouse. First one (the failed one) was done from my Android phone using SSH Client JuiceSSH. The second one (the successful one) was done from my Windows Desktop using SSH client PuTTY. jprochazka’s script was used in both of today’s installs.

abcd567,

I install the same ubuntu on the Orange Pi. But I am having issues getting MLAT and collect to work.


12/28/2015 22:04:21 TLS alert: unknown CA
12/28/2015 22:04:21 TLS error: certificate verify failed
12/28/2015 22:04:21 TLS handshake with adept server at piaware.flightaware.com/1200 failed: handshake failed: certificate verify failed
12/28/2015 22:04:21 reconnecting in 104 seconds...

When I try to restart collectd here is what it shows.


sudo: unable to resolve host OrangePI
....] Restarting collectd (via systemctl): collectd.serviceJob for collectd.service failed. See "systemctl status collectd.service" and "journalctl -xe" for details.
 failed!
pi@OrangePI:~$ 


pi@OrangePI:~$ sudo apt-get install ca-certificates
sudo: unable to resolve host OrangePI
Reading package lists... Done
Building dependency tree       
Reading state information... Done
ca-certificates is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up collectd (5.4.1-6ubuntu1) ...
Job for collectd.service failed. See "systemctl status collectd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript collectd, action "restart" failed.
dpkg: error processing package collectd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 collectd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Did you have any issue with this?

sjacket99@ The "unable to resolve host OrangePI"i ssue can be resolved by adding orangepi to local hosts.
So…


sudo nano /etc/hosts

my hosts file looks like…


127.0.0.1       localhost orangepi
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

then maybe reinstall the CA certificates.

“UBUNTU VIVID MATE” ON ORANGEPI PC - Solved the CA certificate /Handshake/connection to Flightaware server by installing Piaware data feeder following the instruction on Flightaware page. Did not remove the Piaware feeder installed by the jprochazka’s auto install script.

(1) CHECKED LOGS BEFORE RE-INSTALL OF PIAWARE



pi@OrangePI:~$ cat /tmp/piaware.out

01/01/1970 00:00:41 Connecting to FlightAware adept server at piaware.flightaware.com/1200
01/01/1970 00:00:41 ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
01/01/1970 00:00:41 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout
01/01/1970 00:00:41 Started faup1090 (pid 689) to connect to dump1090-mutabi
01/01/1970 00:00:41 Connection with adept server at piaware.flightaware.com/1200 established
01/01/1970 00:00:41 TLS verify failed: self signed certificate in certificate chain
01/01/1970 00:00:41 Failing certificate:
01/01/1970 00:00:41   sha1_hash: B69ABB0BF41433F4E27434BF6628CE1EA1CAA704
01/01/1970 00:00:41   subject: CN=FlightAware Root,OU=Operations,O=FlightAware LLC,L=Houston,ST=TX,C=US
01/01/1970 00:00:41   issuer: CN=FlightAware Root,OU=Operations,O=FlightAware LLC,L=Houston,ST=TX,C=US
01/01/1970 00:00:41   notBefore: Dec  9 16:50:04 2015 GMT
01/01/1970 00:00:41   notAfter: Dec  4 16:50:04 2035 GMT
01/01/1970 00:00:41   serial: A9FE756D9E6B94B4
01/01/1970 00:00:41 TLS alert: unknown CA
01/01/1970 00:00:41 TLS error: certificate verify failed
01/01/1970 00:00:41 TLS handshake with adept server at piaware.flightaware.com/1200 failed: handshake failed: certificate verify failed
01/01/1970 00:00:41 reconnecting in 112 seconds...
01/01/1970 00:00:42 piaware received a message from dump1090-mutabi!
12/29/2015 00:19:25 22 msgs recv'd from dump1090-mutabi; 0 msgs sent to FlightAware
12/29/2015 00:19:25 Connecting to FlightAware adept server at piaware.flightaware.com/1200
12/29/2015 00:19:25 no new messages received in 1451348315 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try to restart dump1090, just in case...
12/29/2015 00:19:25 attempting to restart dump1090-mutability using 'invoke-rc.d dump1090-mutability restart'...
12/29/2015 00:19:28 dump1090 restart appears to have been successful
12/29/2015 00:19:28 Connection with adept server at piaware.flightaware.com/1200 established
12/29/2015 00:19:28 TLS verify failed: self signed certificate in certificate chain
12/29/2015 00:19:28 Failing certificate:
12/29/2015 00:19:28   sha1_hash: B69ABB0BF41433F4E27434BF6628CE1EA1CAA704
12/29/2015 00:19:28   subject: CN=FlightAware Root,OU=Operations,O=FlightAware LLC,L=Houston,ST=TX,C=US
12/29/2015 00:19:28   issuer: CN=FlightAware Root,OU=Operations,O=FlightAware LLC,L=Houston,ST=TX,C=US
12/29/2015 00:19:28   notBefore: Dec  9 16:50:04 2015 GMT
12/29/2015 00:19:28   notAfter: Dec  4 16:50:04 2035 GMT
12/29/2015 00:19:28   serial: A9FE756D9E6B94B4
12/29/2015 00:19:28 TLS alert: unknown CA
12/29/2015 00:19:28 TLS error: certificate verify failed
12/29/2015 00:19:28 TLS handshake with adept server at piaware.flightaware.com/1200 failed: handshake failed: certificate verify failed
12/29/2015 00:19:28 reconnecting in 71 seconds...
12/29/2015 00:19:38 ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
12/29/2015 00:19:38 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout
12/29/2015 00:19:38 Started faup1090 (pid 938) to connect to dump1090-mutabi


(2) RE-INSTALLED PIAWARE: flightaware.com/adsb/piaware/install


 
pi@OrangePI:~$ wget http://flightaware.com/adsb/piaware/files/piaware_2.1-5_armhf.deb
pi@OrangePI:~$ sudo dpkg -i piaware_2.1-5_armhf.deb
pi@OrangePI:~$ sudo apt-get install -fy
pi@OrangePI:~$ sudo piaware-config -autoUpdate 1 -manualUpdate 1
pi@OrangePI:~$ sudo piaware-config -user abcd567 -password
please enter flightaware user abcd567's password:
pi@OrangePI:~$ sudo piaware-config -mlatResultsFormat beast,connect,localhost:30004
pi@OrangePI:~$ sudo /etc/init.d/piaware restart
 ok ] Restarting piaware (via systemctl): piaware.service.


(3) CHECKED PIAWARE LOG AFTER RE-INSTALL



pi@OrangePI:~$ cat /tmp/piaware.out

12/29/2015 00:22:15 Connecting to FlightAware adept server at 70.42.6.198/1200
12/29/2015 00:22:15 Connection with adept server at 70.42.6.198/1200 established
12/29/2015 00:22:15 FlightAware server SSL certificate validated
12/29/2015 00:22:15 encrypted session established with FlightAware
12/29/2015 00:22:15 autoUpdate is not configured in /etc/piaware or by piaware-config
12/29/2015 00:22:15 manualUpdate is not configured in /etc/piaware or by piaware-config
12/29/2015 00:22:15 multilateration support enabled (use piaware-config to disable)
12/29/2015 00:22:16 Receiver location changed, restarting faup1090
12/29/2015 00:22:16 reconnecting to dump1090-mutabi
12/29/2015 00:22:16 logged in to FlightAware as user abcd567
12/29/2015 00:22:16 ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
12/29/2015 00:22:16 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 43.580 --lon -79.624
12/29/2015 00:22:16 Started faup1090 (pid 1388) to connect to dump1090-mutabi
12/29/2015 00:22:16 multilateration support enabled (use piaware-config to disable)
12/29/2015 00:22:16 multilateration data requested, enabling mlat client
12/29/2015 00:22:16 Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30004 --results beast,connect,feed.adsbexchange.com:30005 --udp-transport 70.42.6.198:8068:1810557464
12/29/2015 00:22:16 mlat(1392): fa-mlat-client 0.2.4 starting up
12/29/2015 00:22:16 mlat(1392): Using UDP transport to 70.42.6.198:8068
12/29/2015 00:22:17 mlat(1392): Input connected to localhost:30005
12/29/2015 00:22:17 piaware has successfully sent several msgs to FlightAware!
12/29/2015 00:22:17 mlat(1392): Beast-format results connection with localhost:30004: connection established
12/29/2015 00:22:17 mlat(1392): Beast-format results connection with feed.adsbexchange.com:30005: connection established
12/29/2015 00:22:34 piaware (process 529) is shutting down because it received a shutdown signal (SIGTERM) from the system...
12/29/2015 00:22:34 multilateration data no longer required, disabling mlat client
12/29/2015 00:22:34 removing pidfile /var/run/piaware.pid
12/29/2015 00:22:34 piaware (process 529) is exiting...
12/29/2015 00:22:34 TLS alert: close notify
12/29/2015 00:22:34 ****************************************************
12/29/2015 00:22:34 piaware version 2.1-5 is running, process ID 1430
12/29/2015 00:22:34 your system info is: Linux OrangePI 3.4.39 #1 SMP PREEMPT Mon Oct 12 12:02:29 CEST 2015 armv7l armv7l armv7l GNU/Linux
12/29/2015 00:22:34 Connecting to FlightAware adept server at piaware.flightaware.com/1200
12/29/2015 00:22:34 ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
12/29/2015 00:22:35 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 43.580 --lon -79.624
12/29/2015 00:22:35 Started faup1090 (pid 1466) to connect to dump1090-mutabi
12/29/2015 00:22:35 Connection with adept server at piaware.flightaware.com/1200 established
12/29/2015 00:22:35 FlightAware server SSL certificate validated
12/29/2015 00:22:35 encrypted session established with FlightAware
12/29/2015 00:22:35 autoUpdate in adept config is enabled, allowing update
12/29/2015 00:22:35 manualUpdate in adept config is enabled, allowing update
12/29/2015 00:22:35 multilateration support enabled (use piaware-config to disable)
12/29/2015 00:22:35 logged in to FlightAware as user abcd567
12/29/2015 00:22:36 piaware received a message from dump1090-mutabi!
12/29/2015 00:22:36 piaware has successfully sent several msgs to FlightAware!
12/29/2015 00:22:36 multilateration support enabled (use piaware-config to disable)
12/29/2015 00:22:36 multilateration data requested, enabling mlat client
12/29/2015 00:22:36 Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30004 --results beast,connect,feed.adsbexchange.com:30005 --udp-transport 70.42.6.197:8767:2010871624
12/29/2015 00:22:36 mlat(1476): fa-mlat-client 0.2.4 starting up
12/29/2015 00:22:36 mlat(1476): Using UDP transport to 70.42.6.197:8767
12/29/2015 00:22:36 mlat(1476): Input connected to localhost:30005
12/29/2015 00:22:37 mlat(1476): Beast-format results connection with localhost:30004: connection established
12/29/2015 00:22:37 mlat(1476): Beast-format results connection with feed.adsbexchange.com:30005: connection established
pi@OrangePI:~$


I’ve just rebuilt my receiver after the pi B that was running my dongle decided that it was going to write garbage all over the SD card. I moved my server stuff onto an Odroid C1+, which freed up my Pi 2 for ADS-B. The Pi B was overclocked and pushed to the limit of its cpu capacity running all the various feeders software, so I had a few things like the mlat-radar client and modesmixer running on a separate system. Now I’ve put it all onto the Pi 2, including the stats collection and it has tons of capacity to spare. In the middle of the day, overall CPU barely goes above 20%.

I used jprochazka’s script to install and configure collectd, which was much simpler than doing it by hand last time. Now I just have to reinstate some of the graphs that I had before that are missing in the basic setup.

Thanks. Tried this but it didn’t help.

If i remember right when i was first trying to resolve this some suggestions (google) where to make sure the same name is used in /etc/hosts and /etc/hostname.
goodluck :slight_smile:

I did Google it up and got that part of it fixed. Thanks.

Orange Pi PC / Jessi Xfce (Debian 8 with Xfce desktop)
**Installation of Web Portal/Graphs **

After installing rrdtools and collectd, crontab did not install :frowning:

pi@OrangePI:~/dump-tools$ sudo ./install.sh “crontab”
===== Starting crontab installation of dump-tools! =====
./install.sh: 71: ./install.sh: crontab: not found
./install.sh: 76: ./install.sh: crontab: not found
===== Finished crontab installation! =====
pi@OrangePI:~/dump-tools$

Any suggestions?

If you were using my scripts there is no need to add a “pi” user if one does not exist. Simply execute the install script using the default user you created during setup or the one supplied by the image.

(1) The max range graph is a known issue. THe latitude and longitude of your feeder needs to be manually added to the file /etc/default/dump1090-mutability at this time. Refer to the project’s wiki page at github.com/jprochazka/adsb-feeder/wiki for instructions on configuring this.

(2) Wonder if this was the certificate issue fixed by PiAware v2.1-5. The scripts were updated about 4 days ago to install this version of PiAware.

I am open to suggestions on additional graphs which other feel should be added.

Honestly the cron jobs should not be placed in a users crontab. Instead place it where they should reside in a file within the folder /etc/cron.d/.

I will be making a new topic covering my scripts today. Things are getting confusing here with two separate solutions for graphs and honestly it is hindering me from offering reliable help being I am not sure anymore what anyone is using to generate graphs.

Update:
New topic pertaining to the ADS-B Feeder scripts can be found here: post185906.html

After having a close look at the system logs a while ago after a SD card failure I got a bit suspicious of the constant ~30kb / second of disk writes that the collectd disk activity graph displayed.

http://i.imgur.com/iycLWmV.png

So I gave iotop a run for 4 hours and it shows collectd writing 331mb to disk in that time which roughly tallies with the graph (rpimonitor, the other disk hog wasn’t installed when the the graph was made)

http://i.imgur.com/HO8lIjk.jpg

I would be interested in hearing if others are seeing similar disk activity, or maybe i just have the collectd sample rate set a bit high at 10 seconds.

300+mb in 4 hours to the round-robin databases is going to add up over the course of a month and a year, The RR database over writes its self as required but I’m not sure how good the SD cards inbuilt wear leveling is, it could explains some failures (apart fro Ebay rubbish)

Maybe someone here knows more about these things??

Hmmm…

Can you setup an area in /tmp where it writes?
Allow it to gather in /tmp and once a day (or more), copy it to the SD card.
Then at normal shutdown, have it copy from /tmp to the SD card.
At boot, have it copy the latest from the SD card back to /tmp.

Then, if you have a crash/power loss/etc, at boot, it will recover with data no older then 1 day (or less). You could change that to every hour, or 6 hours, etc.

End result, no constant SD card writes without risk of loosing any significant data. This should be a really easy script…well 3 scripts.

Collectd will defiantly add to disk IO setting the sample rate a bit longer I am sure would help but honestly will only put off the inevitable. After my 3rd SD card over the span of 4 months going bad I switched to putting everything except /boot onto a USB drive which drove my disk IO activity on the SD card to nearly nothing. SD cards are inherently poor at handling as many writes as an OS calls for especially if you wish to add any bells and whistles such as performance graphs. A USB drive is more capable of handling writes than an SD card. Another option is when it is time to replace an SD card go with as big of one as possible. I have read claims that this will extend the life of the SD card a bit longer due to the fact data can be spread out over more sectors.

Here are the steps for transferring an existing installation to a USB drive which I used if you are interested.
ads-b-flight-tracking-f21/running-raspbian-from-a-usb-drive-t36464.html

Why should a USB flash drive last longer than a sdcard? They’re the same underlying technology, both do wear levelling etc.

There is a cacheing daemon for rrd that has a collectd plugin. It is intended to keep a system usable when collecting data from lots of other systems, but it should also reduce the number of writes to disk for a single host.


apt-get install rrdcached

then modify the collectd.conf to enable it.

I tried to get it working on raspbian, but it kept throwing up errors in the journal, and I haven’t had time to go through it to work out why. When I installed it on a different system running arch it worked straight away, so I’m not sure what the problem is.

Looking back I was not very clear.
Instead of saying “USB Drive” should have said “USB Hard Drive”…

Sorry for any confusion or if I mislead anyone.

Ah that makes more sense then. A spinning disk is probably taking more power than the Pi :wink:

True but still less than a full blown computer. It cannot be more than 5v being it is backwards compatible with USB 2 and I see WD claims it draws the max 500mA only at full read/write speed. So all in all not too bad especially being I will be saving 10 bucks a month not having to buy SD cards I see it as a win and a savings over time. :slight_smile: