Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

On 2017-04-26 09:38:09 +0800, Paul Wise wrote:
> On Tue, 2017-04-25 at 17:22 +0200, Aurelien Jarno wrote:
> > Hmm, it only works for one change, after that the .old file will be
> > overwritten causing the data loss. I guess the filename should include
> > the date and time.

Or an index that would increment (".1", ".2", ".3", etc.) until the
file is not found. It would be simpler and sufficient, as the date
and time are already in the mtime of the file.

> Yes, I didn't implement this because my C skills are rusty. Also, the
> time between events should be long so the admin should notice the log
> error before the old file is overwritten and RRD rotates out old data
> anyway AFAIK.

Not necessarily. The user doesn't necessarily look at the RRD data
regularly, but for instance only in case of problems. Then, one may
want to see what happened in the previous months or years[*], to see
if the data were similar.

[*] For instance, it could be the previous summer(s) to have similar
weather (external temperature) conditions.

> Also the old file will be in backups.

It could have been overwritten in backups.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#790796: sensord: RRD data loss

[Paul Wise]

On Tue, 2017-04-25 at 17:22 +0200, Aurelien Jarno wrote:

> What's your use case for sensord without RRD? Logging values and alarms
> into syslog?

Yes, when a machine powers off overnight, having that info in syslog
helps diagnose what happened.

> In that case we might just want to remove/disable RRD support while
> keeping the rest of the features.

I think it would be better to keep it if possible.

> This is true, that said while lm-sensors is dead for a bit less than 2
> years now, there hasn't been any change to sensord for more than 5
> years, and no major change for more than 8 years.

I guess it does what is needed with no major changes?

> Hmm, it only works for one change, after that the .old file will be
> overwritten causing the data loss. I guess the filename should include
> the date and time.

Yes, I didn't implement this because my C skills are rusty. Also, the
time between events should be long so the admin should notice the log
error before the old file is overwritten and RRD rotates out old data
anyway AFAIK. Also the old file will be in backups.

> While that might work (provided we keep multiple versions of the file),
> I think the data are not really usable as each period will have a
> different format. The real way to fix that would be to use one RRD file
> per sensor, but it becomes a major change to the software, and I am not
> sure we want to do that given the dead upstream

I don't intend to work on multiple files as my C skills are rusty.
Agreed that fixing this properly can wait until upstream returns.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

On 2017-04-25 17:22:37 +0200, Aurelien Jarno wrote:
> While that might work (provided we keep multiple versions of the file),
> I think the data are not really usable as each period will have a
> different format. The real way to fix that would be to use one RRD file
> per sensor, but it becomes a major change to the software, and I am not
> sure we want to do that given the dead upstream

Or have a fixed config file. The sensord.cgi file (which reads the RRD
file) is normally fixed, so that this would make sense. If there are
new sensors, they would simply be ignored (until the user regenerates
or rewrites the config file and sensord.cgi). If some sensors are no
longer supported, one would simply get missing values (NaN?) in the
RRD file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#790796: sensord: RRD data loss

[Aurelien Jarno]

On 2017-04-12 12:24, Paul Wise wrote:
> This was an unfortunate outcome for those of us who use sensord but do
> not use the RRD mode at all. I think it would have been better to just
> disable the RRD mode, but that wouldn't have been the right solution.

What's your use case for sensord without RRD? Logging values and alarms
into syslog?

In that case we might just want to remove/disable RRD support while
keeping the rest of the features.

> It seems that all of lm-sensors is dead upstream, not just sensord.

This is true, that said while lm-sensors is dead for a bit less than 2
years now, there hasn't been any change to sensord for more than 5
years, and no major change for more than 8 years.

> On Wed, 2017-04-12 at 10:31 +0800, Paul Wise wrote:
> 
> > I've attached a patch which renames the old RRD file
> > and creates a new one. Could we add it and restore sensord?
 
> Attached a better version of the patch with two fixes:
> 
>  * No memory leak
>  * Updates the new RRD after creation
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

> --- a/prog/sensord/rrd.c
> +++ b/prog/sensord/rrd.c
> @@ -456,8 +456,34 @@
>   "sensord", sensord_args.rrdFile, rrdBuff, NULL
>   };
>   if ((ret = rrd_update(3, (char **) /* WEAK */ argv))) {
> + /* Cope with incompatible RRD files by creating new
> +ones and saving a backup of the old RRD files.   */
> + const char *format = "%s.old";
> + size_t len = strlen(format) - 2 + 
> strlen(sensord_args.rrdFile) + 1;
> + char *backup = (char*)malloc(len);

Hmm, it only works for one change, after that the .old file will be
overwritten causing the data loss. I guess the filename should include
the date and time.

>   sensorLog(LOG_ERR, "Error updating RRD file: %s: %s",
> sensord_args.rrdFile, rrd_get_error());
> + if (backup == NULL)
> + goto cleanup;
> + if (snprintf(backup, len, format, sensord_args.rrdFile) 
> >= len)
> + goto cleanup;
> + if (rename(sensord_args.rrdFile, backup) != 0)
> + goto cleanup;
> + sensorLog(LOG_ERR, "Incompatible RRD file renamed from 
> %s to %s",
> +   sensord_args.rrdFile, backup);
> + ret = rrdInit();
> + if (!ret) {
> + sensorLog(LOG_ERR, "New RRD file created at %s",
> +   sensord_args.rrdFile);
> + ret = rrd_update(3, (char **) /* WEAK */ argv);
> + } else {
> + rename(backup, sensord_args.rrdFile);
> + }
> + cleanup:
> + if (backup != NULL)
> + free(backup);
> + if (ret)
> + return ret;
>   }
>   }
>   sensorLog(LOG_DEBUG, "sensor rrd updated");

While that might work (provided we keep multiple versions of the file),
I think the data are not really usable as each period will have a
different format. The real way to fix that would be to use one RRD file
per sensor, but it becomes a major change to the software, and I am not
sure we want to do that given the dead upstream

Cheers,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#790796: sensord: RRD data loss

[Paul Wise]

On Wed, 2017-04-12 at 10:31 +0800, Paul Wise wrote:

> I've attached a patch which renames the old RRD file
> and creates a new one. Could we add it and restore sensord?

Attached a better version of the patch with two fixes:

 * No memory leak
 * Updates the new RRD after creation

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
--- a/prog/sensord/rrd.c
+++ b/prog/sensord/rrd.c
@@ -456,8 +456,34 @@
 			"sensord", sensord_args.rrdFile, rrdBuff, NULL
 		};
 		if ((ret = rrd_update(3, (char **) /* WEAK */ argv))) {
+			/* Cope with incompatible RRD files by creating new
+			   ones and saving a backup of the old RRD files.   */
+			const char *format = "%s.old";
+			size_t len = strlen(format) - 2 + strlen(sensord_args.rrdFile) + 1;
+			char *backup = (char*)malloc(len);
 			sensorLog(LOG_ERR, "Error updating RRD file: %s: %s",
   sensord_args.rrdFile, rrd_get_error());
+			if (backup == NULL)
+goto cleanup;
+			if (snprintf(backup, len, format, sensord_args.rrdFile) >= len)
+goto cleanup;
+			if (rename(sensord_args.rrdFile, backup) != 0)
+goto cleanup;
+			sensorLog(LOG_ERR, "Incompatible RRD file renamed from %s to %s",
+  sensord_args.rrdFile, backup);
+			ret = rrdInit();
+			if (!ret) {
+sensorLog(LOG_ERR, "New RRD file created at %s",
+	  sensord_args.rrdFile);
+ret = rrd_update(3, (char **) /* WEAK */ argv);
+			} else {
+rename(backup, sensord_args.rrdFile);
+			}
+			cleanup:
+if (backup != NULL)
+	free(backup);
+if (ret)
+	return ret;
 		}
 	}
 	sensorLog(LOG_DEBUG, "sensor rrd updated");


signature.asc
Description: This is a digitally signed message part

Bug#790796: sensord: RRD data loss

[Paul Wise]

Control: tags -1 + patch

On Wed, 2017-04-12 at 08:42 +0800, Paul Wise wrote:

> I'm going to try to write a patch to achieve this now.

I've attached a patch which renames the old RRD file
and creates a new one. Could we add it and restore sensord?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
--- a/prog/sensord/rrd.c
+++ b/prog/sensord/rrd.c
@@ -456,8 +456,31 @@
 			"sensord", sensord_args.rrdFile, rrdBuff, NULL
 		};
 		if ((ret = rrd_update(3, (char **) /* WEAK */ argv))) {
+			/* Cope with incompatible RRD files by creating new
+			   ones and saving a backup of the old RRD files.   */
+			const char *format = "%s.old";
+			size_t len = strlen(format) - 2 + strlen(sensord_args.rrdFile) + 1;
+			char *backup = (char*)malloc(len);
 			sensorLog(LOG_ERR, "Error updating RRD file: %s: %s",
   sensord_args.rrdFile, rrd_get_error());
+			if (backup == NULL)
+goto error;
+			if (snprintf(backup, len, format, sensord_args.rrdFile) >= len)
+goto error;
+			if (rename(sensord_args.rrdFile, backup) != 0)
+goto error;
+			sensorLog(LOG_ERR, "Incompatible RRD file renamed from %s to %s",
+  sensord_args.rrdFile, backup);
+			ret = rrdInit();
+			if (!ret) {
+sensorLog(LOG_ERR, "New RRD file created at %s",
+	  sensord_args.rrdFile);
+			} else {
+rename(backup, sensord_args.rrdFile);
+error:
+	free(backup);
+	return ret;
+			}
 		}
 	}
 	sensorLog(LOG_DEBUG, "sensor rrd updated");


signature.asc
Description: This is a digitally signed message part

Bug#790796: sensord: RRD data loss

[Paul Wise]

On Wed, 05 Apr 2017 12:09:00 + Niels Thykier wrote:

> Sounds like we should just sensord now while it still "sort of works"
> rather than dragging on with it until it breaks irrevocably.

This was an unfortunate outcome for those of us who use sensord but do
not use the RRD mode at all. I think it would have been better to just
disable the RRD mode, but that wouldn't have been the right solution.

I think the correct solution for sensord would be to detect these
situations where the existing RRD file is incompatible, rename the
existing one to to a backup and create a new one. This would mean that
the old data is preserved (but only in a different location) and new
data is recorded as per usual. Given the restrictions of the RRD
format, I think this is the best solution that is easy to do.
I'm going to try to write a patch to achieve this now.

It seems that all of lm-sensors is dead upstream, not just sensord.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#790796: sensord: RRD data loss

[Niels Thykier]

On Sat, 8 Aug 2015 23:30:26 +0200 Aurelien Jarno 
wrote:
> Hi,
> 
> On 2015-07-01 21:08, Vincent Lefevre wrote:
> > Package: sensord
> > Version: 1:3.3.5-2
> > Severity: grave
> > Justification: causes non-serious data loss
> > 
> > It seems that sensord uses an inconsistent set of data for its
> > RRD update, yielding data loss. "rrd update" no longer updates
> > the sensord.rrd database:
> > 
> > -rw-r--r-- 1 root root 82480 2015-05-13 00:25:00 /var/log/sensord.rrd
> > 
> > due to the following errors seen in my /var/log/syslog file:
> > 
> > [...]
> 
> From what I have been able to get the problem is that when using a
> single rrd file for all data, the number of columns (ie sensors) is
> defined when the file is created. Therefore the upgrade of your kernel
> changed the number of sensors, and caused this issue.
> 
> From what I have been able to read in the documentation, one solution
> would be to use the MULTIPLE mode of RRD, which create one file per
> column or sensor. But this format is incompatible with the current one,
> which means people will have to recreate their database, and possibly
> the scripts extracting the data for them.
> 
> I don't really know what is the solution for this bug, one might be to
> stop shipping sensord in Debian as it is kind of dead upstream and not
> build by default.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
> 
> 


Hi,

Sounds like we should just sensord now while it still "sort of works"
rather than dragging on with it until it breaks irrevocably.

Thanks,
~Niels

Bug#790796: sensord

[Aurelien Jarno]

On 2017-01-29 21:46, Vincent Lefevre wrote:
> On 2017-01-29 15:54:36 +, Andy Simpkins wrote:
> > Back in August *2015* there was a short discussion regarding removing
> > sonsord from lm-sensors as a result of this bug.
> > 
> > Because it is marked as GRAVE, this bug is release critical for Stretch.
> > 
> > Is this really a grave bug, should it be down graded?
> 
> This is data loss. Downgrading the bug would be a bad idea.
> Why not just simply fix it?

Strictly speaking it's not data loss. New data is not acquired anymore,
but the old data is still available and not lost.

> > Can Sensord be removed?
> 
> If it is too broken and unfixable, then it should be removed, which
> would be a simple way (though not the best way) to fix the bug as a
> consequence. What's the point of keeping something that no longer
> works?

I disagree it does not longer work to the point it is not longer usable.
The logging to an RRD database is broken in some cases (see below), but
logging to syslog, ie the default configuration, still works perfectly.

Now removing sensord is clearly an option, as it hasn't seen any recent
changes upstream, but also because it's not compiled by default in the
upstream Makefile. The other alternative is disabling the RRD part of
sensord.


> > Is there another option?
> > 
> > It seams to me that if you depend on the structure of a file that
> > changes you could simply re-initialise sensord passing it the new
> > structure.
> 
> What do you mean? Note that rebooting the machine doesn't solve the
> problem. On a different machine, I still have:
> 
> [...]
> Jan 29 21:35:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 0.04
> Jan 29 21:35:00 ypig sensord: rrd update error (-1)
> Jan 29 21:40:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 0.00
> Jan 29 21:40:00 ypig sensord: rrd update error (-1)
> Jan 29 21:45:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 0.14
> Jan 29 21:45:00 ypig sensord: rrd update error (-1)

It's not a question of rebooting the machine, but moving out this RRD
file and creating a new one. The problem is that all the values returned
by the sensor drivers are stored in a single file, so the problem arise
if the number of value to be stored changes since the file has been
created. This means that loading or unloading sensors modules, or using
a new kernel which changes the values returned by some sensors modules
will trigger this issue. This is why the manpage states "It is expected
that all required sensor modules are loaded prior to this daemon being
started".

Please also note that it's not a new bug that has been introduced
recently, it has probably always been there and can easily be triggered
by loading or unloading kernel modules.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#790796: sensord

[Vincent Lefevre]

On 2017-01-29 15:54:36 +, Andy Simpkins wrote:
> Back in August *2015* there was a short discussion regarding removing
> sonsord from lm-sensors as a result of this bug.
> 
> Because it is marked as GRAVE, this bug is release critical for Stretch.
> 
> Is this really a grave bug, should it be down graded?

This is data loss. Downgrading the bug would be a bad idea.
Why not just simply fix it?

> Can Sensord be removed?

If it is too broken and unfixable, then it should be removed, which
would be a simple way (though not the best way) to fix the bug as a
consequence. What's the point of keeping something that no longer
works?

> Is there another option?
> 
> It seams to me that if you depend on the structure of a file that
> changes you could simply re-initialise sensord passing it the new
> structure.

What do you mean? Note that rebooting the machine doesn't solve the
problem. On a different machine, I still have:

[...]
Jan 29 21:35:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 0.04
Jan 29 21:35:00 ypig sensord: rrd update error (-1)
Jan 29 21:40:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 0.00
Jan 29 21:40:00 ypig sensord: rrd update error (-1)
Jan 29 21:45:00 ypig sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 0.14
Jan 29 21:45:00 ypig sensord: rrd update error (-1)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#790796: sensord

[Andy Simpkins]

Hi there,

Back in August *2015* there was a short discussion regarding removing
sonsord from lm-sensors as a result of this bug.

Because it is marked as GRAVE, this bug is release critical for Stretch.

Is this really a grave bug, should it be down graded?  Can Sensord be
removed?  Is there another option?

It seams to me that if you depend on the structure of a file that
changes you could simply re-initialise sensord passing it the new structure.

However I suspect that I am trivialising the underlying issue...



/Andy

Bug#790796: sensord: RRD data loss

[Aurelien Jarno]

On 2015-08-09 00:21, Vincent Lefevre wrote:
 Hi,
 
 On 2015-08-08 23:30:26 +0200, Aurelien Jarno wrote:
  From what I have been able to get the problem is that when using a
  single rrd file for all data, the number of columns (ie sensors) is
  defined when the file is created. Therefore the upgrade of your kernel
  changed the number of sensors, and caused this issue.
  
  From what I have been able to read in the documentation, one solution
  would be to use the MULTIPLE mode of RRD, which create one file per
  column or sensor. But this format is incompatible with the current one,
  which means people will have to recreate their database, and possibly
  the scripts extracting the data for them.
 
 This could be an option (set by default to avoid problems in the
 future). But anyway, after upgrading the kernel (even a security
 update!), the database is currently no longer usable. So, this
 would not be worse than the current situation.

I will try to look if it is something doable.

  I don't really know what is the solution for this bug, one might be to
  stop shipping sensord in Debian as it is kind of dead upstream and not
  build by default.
 
 Is there a replacement?

Well I am not sure we need a replacement for something which is just
unusable.

That said, yes there are replacements. I am personally using munin to
plot temperatures/voltages/fan speed graphs, but I am sure there are
plenty of other monitoring system.

 Or perhaps it's easy enough for the user to write a daemon in a
 shell/Perl/whatever script by executing the sensors utility. BTW,
 I already have written such a utility in Perl, which supports
 CPU load, disk usage and entropy. Adding sensors support would
 really be easy.

Or by using libsensors instead of parsing the output of sensors, which
might slightly change over the time.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Aurelien Jarno]

Hi,

On 2015-07-01 21:08, Vincent Lefevre wrote:
 Package: sensord
 Version: 1:3.3.5-2
 Severity: grave
 Justification: causes non-serious data loss
 
 It seems that sensord uses an inconsistent set of data for its
 RRD update, yielding data loss. rrd update no longer updates
 the sensord.rrd database:
 
 -rw-r--r-- 1 root root 82480 2015-05-13 00:25:00 /var/log/sensord.rrd
 
 due to the following errors seen in my /var/log/syslog file:
 
 [...]
 Jul  1 20:30:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
 /var/log/sensord.rrd: found extra data on update argument: 
 67.0:67.0:66.0:74.0:1.58
 Jul  1 20:30:00 xvii sensord: rrd update error (-1)
 Jul  1 20:35:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
 /var/log/sensord.rrd: found extra data on update argument: 
 62.0:54.0:57.0:69.0:0.52
 Jul  1 20:35:00 xvii sensord: rrd update error (-1)
 Jul  1 20:40:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
 /var/log/sensord.rrd: found extra data on update argument: 
 66.0:62.0:64.0:72.0:1.33
 Jul  1 20:40:00 xvii sensord: rrd update error (-1)
 Jul  1 20:45:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
 /var/log/sensord.rrd: found extra data on update argument: 
 63.0:54.0:57.0:70.0:0.54
 Jul  1 20:45:00 xvii sensord: rrd update error (-1)
 Jul  1 20:50:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
 /var/log/sensord.rrd: found extra data on update argument: 
 60.0:54.0:59.0:66.0:0.30
 Jul  1 20:50:00 xvii sensord: rrd update error (-1)
 [...]

From what I have been able to get the problem is that when using a
single rrd file for all data, the number of columns (ie sensors) is
defined when the file is created. Therefore the upgrade of your kernel
changed the number of sensors, and caused this issue.

From what I have been able to read in the documentation, one solution
would be to use the MULTIPLE mode of RRD, which create one file per
column or sensor. But this format is incompatible with the current one,
which means people will have to recreate their database, and possibly
the scripts extracting the data for them.

I don't really know what is the solution for this bug, one might be to
stop shipping sensord in Debian as it is kind of dead upstream and not
build by default.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

Hi,

On 2015-08-08 23:30:26 +0200, Aurelien Jarno wrote:
 From what I have been able to get the problem is that when using a
 single rrd file for all data, the number of columns (ie sensors) is
 defined when the file is created. Therefore the upgrade of your kernel
 changed the number of sensors, and caused this issue.
 
 From what I have been able to read in the documentation, one solution
 would be to use the MULTIPLE mode of RRD, which create one file per
 column or sensor. But this format is incompatible with the current one,
 which means people will have to recreate their database, and possibly
 the scripts extracting the data for them.

This could be an option (set by default to avoid problems in the
future). But anyway, after upgrading the kernel (even a security
update!), the database is currently no longer usable. So, this
would not be worse than the current situation.

 I don't really know what is the solution for this bug, one might be to
 stop shipping sensord in Debian as it is kind of dead upstream and not
 build by default.

Is there a replacement?

Or perhaps it's easy enough for the user to write a daemon in a
shell/Perl/whatever script by executing the sensors utility. BTW,
I already have written such a utility in Perl, which supports
CPU load, disk usage and entropy. Adding sensors support would
really be easy.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

On 2015-07-01 21:08:19 +0200, Vincent Lefevre wrote:
 It seems that sensord uses an inconsistent set of data for its
 RRD update, yielding data loss. rrd update no longer updates
 the sensord.rrd database:
[...]

This has happened again on a different machine. The update of
the RRD database stopped a few days ago:

-rw-r--r-- 1 root root 213992 2015-07-23 16:45:00 sensord.rrd

apparently due to a security update of the kernel:

2015-07-23 16:45:59 upgrade linux-image-3.16.0-4-amd64:amd64 3.16.7-ckt11-1 
3.16.7-ckt11-1+deb8u2
2015-07-23 16:45:59 status half-configured linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1
2015-07-23 16:45:59 status unpacked linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1
2015-07-23 16:45:59 status half-installed linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1
2015-07-23 16:46:09 status half-installed linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1
2015-07-23 16:46:09 status unpacked linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2
2015-07-23 16:46:09 status unpacked linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2
[...]
2015-07-23 16:47:01 configure linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2 none
2015-07-23 16:47:01 status unpacked linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2
2015-07-23 16:47:01 status half-configured linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2
2015-07-23 16:47:07 status installed linux-image-3.16.0-4-amd64:amd64 
3.16.7-ckt11-1+deb8u2

which corresponds to:

linux (3.16.7-ckt11-1+deb8u2) jessie-security; urgency=high

  * [amd64] Restore perf/x86: Further optimize copy_from_user_nmi()
  * [amd64] Fix nested NMI handling (CVE-2015-3290, CVE-2015-3291)
- Enable nested do_nmi handling for 64-bit kernels
- Remove asm code that saves cr2
- Switch stacks on userspace NMI entry
- Reorder nested NMI checks
- Use DF to avoid userspace RSP confusing nested NMI detection

 -- Ben Hutchings b...@decadent.org.uk  Fri, 17 Jul 2015 21:28:00 +0100

linux (3.16.7-ckt11-1+deb8u1) jessie-security; urgency=medium

  * udf: Remove repeated loads blocksize
  * udf: Check length of extended attributes and allocation descriptors
(CVE-2015-4167)
  * udp: fix behavior of wrong checksums (CVE-2015-5364, CVE-2015-5366)
  * [amd64] Revert perf/x86: Further optimize copy_from_user_nmi()
(CVE-2015-3290)

 -- Ben Hutchings b...@decadent.org.uk  Thu, 16 Jul 2015 20:18:18 +0100

The syslog file contains errors like:

Jul 27 17:00:00 zira sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: expected 13 data source readings (got 12) from N
Jul 27 17:00:00 zira sensord: rrd update error (-1)

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

It seems to be a bug similar to bug 614965.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

Package: sensord
Version: 1:3.3.5-2
Severity: grave
Justification: causes non-serious data loss

It seems that sensord uses an inconsistent set of data for its
RRD update, yielding data loss. rrd update no longer updates
the sensord.rrd database:

-rw-r--r-- 1 root root 82480 2015-05-13 00:25:00 /var/log/sensord.rrd

due to the following errors seen in my /var/log/syslog file:

[...]
Jul  1 20:30:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 
67.0:67.0:66.0:74.0:1.58
Jul  1 20:30:00 xvii sensord: rrd update error (-1)
Jul  1 20:35:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 
62.0:54.0:57.0:69.0:0.52
Jul  1 20:35:00 xvii sensord: rrd update error (-1)
Jul  1 20:40:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 
66.0:62.0:64.0:72.0:1.33
Jul  1 20:40:00 xvii sensord: rrd update error (-1)
Jul  1 20:45:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 
63.0:54.0:57.0:70.0:0.54
Jul  1 20:45:00 xvii sensord: rrd update error (-1)
Jul  1 20:50:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
/var/log/sensord.rrd: found extra data on update argument: 
60.0:54.0:59.0:66.0:0.30
Jul  1 20:50:00 xvii sensord: rrd update error (-1)
[...]

The sensord package hasn't changed since 2014-05-10, and its config
files are even older:

-rw-r--r-- 1 root root   714 2011-10-13 01:48:46 /etc/default/sensord
-rwxr-xr-x 1 root root  1820 2011-02-06 14:46:22 /etc/init.d/sensord*
-rw-r--r-- 1 root root 10344 2012-04-23 19:03:35 /etc/sensors3.conf

So, it broke itself alone after a kernel update:

runlevel (to lvl 2)   Wed May 13 00:27 - 19:31 (9+19:03)4.0.0-1-amd64
reboot   system boot  Wed May 13 00:27 - 19:31 (9+19:03)4.0.0-1-amd64
shutdown system down  Wed May 13 00:26 - 00:27  (00:01) 3.16.0-4-amd64
runlevel (to lvl 6)   Wed May 13 00:26 - 00:26  (00:00) 3.16.0-4-amd64

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sensord depends on:
ii  libc62.19-18
ii  librrd4  1.4.8-1.3+b2
ii  libsensors4  1:3.3.5-2
ii  lm-sensors   1:3.3.5-2
ii  lsb-base 4.1+Debian13+nmu1

sensord recommends no packages.

Versions of packages sensord suggests:
ii  rrdtool  1.4.8-1.3+b2

-- Configuration Files:
/etc/default/sensord changed:
ALARM_INTERVAL=1m
LOG_INTERVAL=30m
SYSLOG_FACILITY=daemon
CONFIG_FILE=/etc/sensors3.conf
RRD_FILE=/var/log/sensord.rrd
RRD_INTERVAL=5m
RRD_LOADAVG=yes

/etc/logcheck/ignore.d.server/sensord e372078bb484de645d0812abdc929c02 [Errno 
2] No such file or directory: u'/etc/logcheck/ignore.d.server/sensord 
e372078bb484de645d0812abdc929c02'

-- 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