Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve database logging when a crashed table is encountered #3070

Closed
YongBoLiu opened this issue Nov 5, 2019 · 7 comments
Closed

Improve database logging when a crashed table is encountered #3070

YongBoLiu opened this issue Nov 5, 2019 · 7 comments
Labels
bug Undesired behaviour resolved A fixed issue
Milestone

Comments

@YongBoLiu
Copy link
Contributor

Describe the bug
A clear and concise description of what the bug is.
An error of division by zero shows up, but real cause is the poller_item table crashed, as below. And the no errors about the SQL reported in the Clog.

2019/11/05 14:25:08 - CMDPHP PHP ERROR WARNING Backtrace: (/poller_boost.php[137]:output_rrd_data(), /poller_boost.php[298]:CactiErrorHandler())

2019/11/05 14:25:08 - ERROR PHP WARNING: Division by zero in file: /opt/cacti/poller_boost.php on line: 298

MariaDB [cacti]> SELECT po.output, po.time, UNIX_TIMESTAMP(po.time) as unix_time, po.local_data_id, dl.data_template_id, pi.rrd_path, pi.rrd_name, pi.rrd_num FROM poller_output AS po INNER JOIN poller_item AS pi ON po.local_data_id=pi.local_data_id AND po.rrd_name=pi.rrd_name INNER JOIN data_local AS dl ON dl.id=po.local_data_id ORDER BY po.local_data_id;
ERROR 144 (HY000): Table './cacti/poller_item' is marked as crashed and last (automatic?) repair failed

To Reproduce
Steps to reproduce the behavior:

  1. Make a table crash, such as poller_item
  2. Run a SQL about the table.
  3. Check the Clog

Expected behavior
A clear and concise description of what you expected to happen.
The DB error should be reported correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS]
  • Browser [e.g. chrome, safari]
  • Version [e.g. 22]
    Linux 7
    Firefox 60

Smartphone (please complete the following information):

  • Device: [e.g. iPhone6]
  • OS: [e.g. iOS8.1]
  • Browser [e.g. stock browser, safari]
  • Version [e.g. 22]
    cacti 1.2.7

Additional context
Add any other context about the problem here.
The errorcode compare in the db_execute_prepared() is NOT right. Because a string always equal with 0. As below,


[root@yboliu_rhel720 /]# php -r "if('HY000' > 0) echo 'Bigger '; if('HY000' == 0) echo 'equal ';"
equal [root@yboliu_rhel720 /]# 

@YongBoLiu
Copy link
Contributor Author

How about fix it as below, I am not very sure we should take the '01000' as succeed.

diff -u -N rtm/cacti/lib/database.php rtm/cacti/lib/database.php
--- rtm/cacti/lib/database.php	2019-08-01 22:33:00.000000000 +0800
+++ rtm/cacti/lib/database.php	2019-11-05 16:16:42.000000970 +0800
@@ -252,12 +252,12 @@
 
 		if ($code == 0) {
 			$code = $query->errorCode();
-			if ($code > 0) {
+			if ($code != '00000' && $code != '01000') {
 				$errorinfo = $query->errorInfo();
 				$en = $errorinfo[1];
 			}  else {
 				$code = $db_conn->errorCode();
-				if ($code > 0) {
+				if ($code != '00000' && $code != '01000') {
 					$errorinfo = $db_conn->errorInfo();
 					$en = $errorinfo[1];
 				}
Ref: https://www.php.net/manual/en/pdo.errorcode.php

@YongBoLiu
Copy link
Contributor Author

[root@yboliu_rhel720 /]# php -v
PHP 5.4.16 (cli) (built: Jan 23 2018 07:26:54)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

@netniV
Copy link
Member

netniV commented Nov 5, 2019

Because 01000 means data truncated which can happen in string description fields especially when take from snmp directly. It is basically a warning not an error.

@YongBoLiu YongBoLiu changed the title DB errorCode is not reported correctly when a table crashed DB errorCode HY000 is not reported correctly when a table crashed Nov 6, 2019
@YongBoLiu
Copy link
Contributor Author

@netniV , thanks. So, we need to fix the db_execute_prepared(). Because it can't report error messages correctly when there are letters in the errorcode, such as HY000.

@netniV
Copy link
Member

netniV commented Nov 6, 2019

Yeah, that seems reasonable to me.

@netniV
Copy link
Member

netniV commented Nov 6, 2019

Actually, this is a fundamental chance that I think should really be done in the 1.3.0 release. We could suddenly be swamped with error messages that were not previously presented and these may not come out during a standard patch testing cycle but only with end users.

@cigamit
Copy link
Member

cigamit commented Nov 9, 2019

Well, that is very interesting. I'll correct the divide by zero, and then conduct a little more research on the crashed table in the few hours I have left.

@cigamit cigamit changed the title DB errorCode HY000 is not reported correctly when a table crashed Improve database logging when a crashed table is encountered Nov 9, 2019
cigamit added a commit that referenced this issue Nov 9, 2019
DB errorCode HY000 is not reported correctly when a table crashed.  There is more to this change before it's closed though.
cigamit added a commit that referenced this issue Nov 9, 2019
Improve database logging when a crashed table is encountered
@cigamit cigamit added bug Undesired behaviour resolved A fixed issue labels Nov 9, 2019
@cigamit cigamit added this to the v1.2.8 milestone Nov 9, 2019
@cigamit cigamit closed this as completed Nov 9, 2019
@github-actions github-actions bot locked and limited conversation to collaborators Jun 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Undesired behaviour resolved A fixed issue
Projects
None yet
Development

No branches or pull requests

3 participants