I wonder if this issue was introduced between 3.0.0 and 3.0.3 -- I am using the code from 3.0.x branch (soon to be 3.0.5) and Andrea is using 3.0.3.
Cheers, Bernard On 7/27/07, aurbain <[EMAIL PROTECTED]> wrote: > > Am running v3.0.4 here, same issue. NTP is properly configured on all > 500 boxes. > > > Bernard Li wrote: > > 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 > > > > > > ------------------------------------------------------------------------- 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
