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