perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

Hi,

Can you send me /var/log/httpd/error_log? Also, can you try running the following commands and send me the output:

/sbin/service cassandra restart

/sbin/service httpd restart

Also, was this originally a 3.3 NetInstall (or older) or was it installed some other way?

Thanks,

Andy

On Oct 16, 2014, at 10:29 AM, John-Paul Robinson <> wrote:

Hi Andrew,

I had rebooted and did again this morning.  No yum updates are pending at this time.

I just noticed that my "old" throughput tests are in fact accessible and working just find at the link:

https://perfsonar-10g-scidmz.uabgrid.uab.edu/serviceTest/index.cgi?eventType=bwctl

The interface and data are still there but I can't seem to get to it through the front page.

The place where I see the error is from clicking on the Throughput/Latency Graphs link on the left side of the web interface.  It loads a new page (instead of the one above) with a spinning wait icon.  After the icon spins around I get the error:

https://perfsonar-10g-scidmz.uabgrid.uab.edu/serviceTest/psGraph.cgi

So my data is all good, just don't know how to get to it through the new front page.  I read over the updates link but don't see anything there that helps (btw my automatic updates were config'd from the cmd line).

~jpr

On 10/16/2014 06:44 AM, Andrew Lake wrote:

Hi,

Have you tried rebooting the host? The 3.4 update requires a reboot to complete the upgrade. See the notes we have plastered on the "enabled services" web page, in our release email and in the docs (http://docs.perfsonar.net/manage_update.html#automatic-updates) regarding the limitations of auto-updates.

Thanks,

Andy

On Oct 15, 2014, at 5:51 PM, John-Paul Robinson <> wrote:

Hi,

So...automatic yum updates are good for catching critical vulnerabilities.

Apparently, they are are not so good for maintaining the state of my service.

http://perfsonar-10g-scidmz.uabgrid.uab.edu/serviceTest/psGraph.cgi

I never explicitly requested an upgrade to 3.4 but seem to have gotten some of the bits anyway:

[jpr@perfsonar-10G-scidmz ~]$ rpm -qa | grep -i perfsonar
perl-perfSONAR_PS-SNMPMA-3.3-4.pSPS.noarch
perl-perfSONAR_PS-serviceTest-3.4-13.pSPS.noarch
perl-perfSONAR_PS-MeshConfig-JSONBuilder-3.4-13.pSPS.noarch
perl-perfSONAR_PS-PingER-server-3.3-1.pSPS.noarch
perl-perfSONAR-OPPD-MP-Shared-3.4-2.pSPS.noarch
perl-perfSONAR-OPPD-MP-server-3.4-2.pSPS.noarch
perl-perfSONAR_PS-Toolkit-3.4-26.pSPS.noarch
perl-perfSONAR_PS-perfSONARBUOY-client-3.3.2-1.pSPS.noarch
perl-perfSONAR_PS-TracerouteMA-server-3.3.2-1.pSPS.noarch
perl-perfSONAR_PS-Toolkit-SystemEnvironment-3.4-26.pSPS.noarch
perl-perfSONAR_PS-MeshConfig-Agent-3.4-13.pSPS.noarch
perl-perfSONAR-OPPD-MP-BWCTL-3.4-2.pSPS.noarch
perl-perfSONAR_PS-SimpleLS-BootStrap-client-3.4-3.pSPS.noarch
perl-perfSONAR_PS-LSRegistrationDaemon-3.4-2.pSPS.noarch
perl-perfSONAR_PS-perfSONARBUOY-config-3.3.2-1.pSPS.noarch
perl-perfSONAR_PS-perfSONARBUOY-server-3.3.2-1.pSPS.noarch
perl-perfSONAR_PS-TracerouteMA-client-3.3.2-1.pSPS.noarch
perl-perfSONAR_PS-TracerouteMA-config-3.3.2-1.pSPS.noarch
perl-perfSONAR-OPPD-MP-OWAMP-3.4-2.pSPS.noarch
perl-perfSONAR_PS-LSCacheDaemon-3.4-1.pSPS.noarch
perl-perfSONAR_PS-RegularTesting-3.4-15.pSPS.noarch
perl-perfSONAR_PS-MeshConfig-Shared-3.4-13.pSPS.noarch

My throughput and traceroute tests both report "Error retrieving test data: undefined".  The traceroute error adds that it's a 500 internal server error, so maybe some backend is dead.

Looking at the regular testing log it appears there is still some regular testing and logging going on.  I see updates to tables and test that look like they are doing what they are supposed to do,  so maybe this is just a problem with the visualizer component.

This is what I see in my httpd error_log when trying to view the throughput tests:

[Wed Oct 15 16:43:35 2014] [error] path= ['/opt/esmond/esmond', '/opt/esmond/lib/python2.7', '/opt/esmond/src/dlnetsnmp/lib', '/opt/esmond', '/opt/esmond/lib64/python27.zip', '/opt/esmond/lib64/python2.7', '/opt/esmond/lib64/python2.7/plat-linux2', '/opt/esmond/lib64/python2.7/lib-tk', '/opt/esmond/lib64/python2.7/lib-old', '/opt/esmond/lib64/python2.7/lib-dynload', '/opt/rh/python27/root/usr/lib64/python2.7', '/opt/rh/python27/root/usr/lib/python2.7', '/opt/esmond/lib/python2.7/site-packages']
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Checking/creating column families
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Schema check done
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [DEBUG] Opening ConnectionPool
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Connected to ['localhost:9160']
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Checking/creating column families
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Checking/creating column families
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Schema check done
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Schema check done
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [DEBUG] Opening ConnectionPool
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [DEBUG] Opening ConnectionPool
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Connected to ['localhost:9160']
[Wed Oct 15 16:43:36 2014] [error] cassandra_db [INFO] Connected to ['localhost:9160']
[Wed Oct 15 16:43:36 2014] [error] begin_ts=1410731016, end_ts=1413409416
[Wed Oct 15 16:43:36 2014] [error] begin=2014-09-14 21:43:36+00:00, end=2014-10-15 21:43:36+00:00

I looked over the update notes but don't see anything that applies.  The comment about checking on the data upgrade doesn't seem to work:

$ sudo less /var/log/perfsonar_ps/psb_to_esmond.log
/var/log/perfsonar_ps/psb_to_esmond.log: No such file or directory

Hoping to get some clarity.

~jpr