I noticed that one of my servers just have the same issue -- rrd_update trying to update using time same as the last update time... not sure why it happens here -- perhaps a bug.
Cheers, Bernard On 7/27/07, Andrea Capriotti <[EMAIL PROTECTED]> wrote: > Il giorno ven, 27/07/2007 alle 07.20 +0100, richard grevis ha scritto: > > This used to happen intermittently with us too. In our case > > > > - It occured with gmond data from windows hosts. > > - The data from the agent leapt back about a month and a half. > > but your leap seems to be 2 years. > > - THE TIMES ON SERVER AND AGENT WERE FINE AND CORRECT. > > - It was the gmond that reported wrong times. > > Same problem here, after a migration to a new machine, OS (SUSE SLES 9 > from Fedora) and ganglia version (3.0.3 from 3.0.0): > > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/mem_total.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/cpu_aidle.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/bytes_in.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/mem_buffers.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/mem_shared.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/swap_total.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > Jul 27 15:40:43 tanabis /usr/sbin/gmetad[2941]: RRD_update > (/dev/shm/ganglia/rrds/BCX_Linux_Cluster/__SummaryInfo__/part_max_used.rrd): > illegal attempt to update using time 1185543615 when last update time is > 1185543615 (minimum one second step) > > Always with the same timestamp. > > We have 6 data sources, a central gmetad in the web frontend machine and > all the clusters nodes are syncronized with an ntp server. > > For example: > > # telnet xxx.xxx.xxx.xxx 8651 | grep LOCALTIME > <GRID NAME="CINECA" AUTHORITY="http://xxxxxxx" LOCALTIME="1185534734"> > <CLUSTER NAME="BCC_Linux_Cluster" LOCALTIME="1185534726" OWNER="CINECA" > LATLONG="unspecified" URL="http://xxxxxx"> > > Any idea? > > Best Regards > -- > Andrea Capriotti > System Management Group - Cineca - www.cineca.it > [EMAIL PROTECTED] - Tel +39 051 6171890 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Ganglia-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ganglia-general > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general

