Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)
On Sat, 24 Sep 2016, Sebastian Harl wrote: > Is this still happening? I believe there were a few fixes that could be > related to this in the past years. If it's still happening, we'll have > to look into more details. I wouldn't know if the bug still exists: I have stopped using collectd a long while ago. Sorry I can't give you better info anymore. -- Henrique Holschuh
Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)
severity 600433 normal thanks On Sun, Oct 17, 2010 at 11:02:11AM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 17 Oct 2010, Florian Forster wrote: > > On Sun, Oct 17, 2010 at 03:32:36AM -0200, Henrique de Moraes Holschuh wrote: > > > collectd[2139]: uc_update: Value too old:name = > > > /temperature-temp1; value time = 1287260393; last cache update = > > > 1287260393; > > > > If the timestamp was influenced by the timezone shift, "value time" > > should be 1-3600 seconds smaller than "last cache update" [0]. The two > > values are identical, though, which is 99.9% of all cases means that the > > identifier ((file)name of the data) is not unique. Maybe the names > > If you mean the full path, then there is no colision. If you mean just the > file-name (temperature-temp1), then there are many colisions. I don't think > that was it. > > I did better checking now (heh, "repeats the error of the past" seems to > apply to me very well...). It was a few hours away from the DST change, so > my report was utterly bogus. I apologise for that. > > It happened three times, to all sensors, including those who would have no > collision across different directories (i.e. unique filename). Looks more > like collectd tried to store the same data twice. > > It all happened on the same "minute". Only other event of note is that cron > started the cron.hourly scripts at that same minute, a few seconds earlier. > However, I am _not_ seeing trouble every hour. Is this still happening? I believe there were a few fixes that could be related to this in the past years. If it's still happening, we'll have to look into more details. Cheers, Sebastian -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)
Hi Henrique, On Sun, Oct 17, 2010 at 03:32:36AM -0200, Henrique de Moraes Holschuh wrote: collectd does not use UTC. collectd uses the timestamp returned by time(3). To the best of my knowledge, it returns the number of seconds since 00:00:00 January 1st, 1970 _UTC_ and should, as such, not be dependent on any timezone setting. collectd[2139]: uc_update: Value too old:name = REMOVED/temperature-temp1; value time = 1287260393; last cache update = 1287260393; If the timestamp was influenced by the timezone shift, value time should be 1-3600 seconds smaller than last cache update [0]. The two values are identical, though, which is 99.9% of all cases means that the identifier ((file)name of the data) is not unique. Maybe the names returned by lm_sensors are not unique or you're collecting the temperature of the same HDD twice.. Either way, the timezone shift is just coincidental. Regards, --octo [0] If the time jumped forwards (== bigger) then there wouldn't be an error message, just a gap in the data. -- Florian octo Forster Hacker in training GnuPG: 0x0C705A15 http://octo.it/ signature.asc Description: Digital signature
Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)
retitle 600433 collectd: rrd: issuing uc_update: Value too old messages thanks On Sun, 17 Oct 2010, Florian Forster wrote: On Sun, Oct 17, 2010 at 03:32:36AM -0200, Henrique de Moraes Holschuh wrote: collectd does not use UTC. collectd uses the timestamp returned by time(3). To the best of my knowledge, it returns the number of seconds since 00:00:00 January 1st, 1970 _UTC_ and should, as such, not be dependent on any timezone setting. Indeed, time(2) does not suffer changes due to timezone and DST. collectd[2139]: uc_update: Value too old:name = REMOVED/temperature-temp1; value time = 1287260393; last cache update = 1287260393; If the timestamp was influenced by the timezone shift, value time should be 1-3600 seconds smaller than last cache update [0]. The two values are identical, though, which is 99.9% of all cases means that the identifier ((file)name of the data) is not unique. Maybe the names If you mean the full path, then there is no colision. If you mean just the file-name (temperature-temp1), then there are many colisions. I don't think that was it. I did better checking now (heh, repeats the error of the past seems to apply to me very well...). It was a few hours away from the DST change, so my report was utterly bogus. I apologise for that. It happened three times, to all sensors, including those who would have no collision across different directories (i.e. unique filename). Looks more like collectd tried to store the same data twice. It all happened on the same minute. Only other event of note is that cron started the cron.hourly scripts at that same minute, a few seconds earlier. However, I am _not_ seeing trouble every hour. Full ntp is running on this box, so time(2) is stable. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)
Package: collectd Version: 4.10.1-1+squeeze1 Severity: important Tags: upstream Those who do not learn from the past, are bound to repeat the same errors forever. collectd does not use UTC. Yet, it expects to be able to ignore timezone shifts that happen twice an year on a very very large number of systems. It results in this sort of crap: collectd[2139]: Filter subsystem: Built-in target `write': Dispatching value to all write plugins failed with status -1. collectd[2139]: uc_update: Value too old:name = REMOVED/temperature-temp1; value time = 1287260393; last cache update = 1287260393; being logged to syslog, for an entire hour. And it obviously inserts a lot of bogosity in the RRD. It needs to detect transitions in and out of DST, and do the right thing. If it doesn't want to deal with this, it MUST use UTC. Entering DST (non-UTC wall time goes forward): cleanly skip one hour (leave a hole in the RRD). Leaving DST (non-UTC wall time goes backwards): do NOT log to the RRD either the hour preceding the DST-ST change, or the hour right after the DST-ST change. Maybe RRDtool safeties against braindamage will already enforce this (I didn't test). And, obviously, log just ONCE to syslog that it is dealing with timezone shift. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32.23 (SMP w/8 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages collectd depends on: ii collectd-core 4.10.1-1+squeeze1 statistics collection and monitori ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii librrd41.4.3-1 time-series data storage and displ Versions of packages collectd recommends: ii iptables1.4.8-3 administration tools for packet fi ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libdbi0 0.8.2-3 Database Independent Abstraction L ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdbus-glib-1-20.88-2 simple interprocess messaging syst ii libesmtp5 1.0.4-5 LibESMTP SMTP client library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-1 FreeType 2 font engine, shared lib ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface ii libhal1 0.5.14-3 Hardware Abstraction Layer - share pn libmemcached5 none (no description available) ii libmysqlclient165.1.49-1 MySQL database client library ii libnotify1 [libnotify1-gtk2 0.5.0-2 sends desktop notifications to a n pn libopenipmi0none (no description available) pn liboping0 none (no description available) ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libpcap0.8 1.1.1-2 system interface for user-level pa ii libperl5.10 5.10.1-14shared Perl library pn libpq5 none (no description available) pn libprotobuf-c0 none (no description available) ii libpython2.62.6.6-3 Shared Python runtime library (ver ii librrd4 1.4.3-1 time-series data storage and displ ii libsensors4 1:3.1.2-6library to read temperature/voltag ii libsnmp15 5.4.3~dfsg-1 SNMP (Simple Network Management Pr ii libssl0.9.8 0.9.8o-2 SSL shared libraries pn libtokyotyrant3 none (no description available) ii libupsclient1 2.4.3-1+b1 network UPS tools - client library ii libvirt00.8.3-3 library for interfacing with diffe ii libxml2 2.7.7.dfsg-4 GNOME XML library pn libyajl1none (no description available) collectd suggests no packages. -- Configuration Files: /etc/collectd/collectd.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
