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

Database reconnection can cause errors to be reported incorrectly #5612

Closed
eriksejr opened this issue Dec 11, 2023 · 4 comments
Closed

Database reconnection can cause errors to be reported incorrectly #5612

eriksejr opened this issue Dec 11, 2023 · 4 comments
Labels
bug Undesired behaviour confirmed Bug is confirm by dev team resolved A fixed issue
Milestone

Comments

@eriksejr
Copy link
Contributor

eriksejr commented Dec 11, 2023

After an upgrade to 1.2.25 I also pulled the develop branch of thold from git and updated it. I started to have problems with thold_daemon not doing anything. These problems showed up as cacti constantly sending me emails that the daemon process was not running, when in fact it was. It just was never updating the "heartbeat" value in the settings table in the database.

Debugging the daemon by running it with --debug --foreground revealed that it constantly said there was no connection to the database, but everything else cacti-related was working just fine, so I dug deeper...

I noticed that in the main loop of thold_daemon.php, you call db_check_reconnect() from lib/database.php and use the return value in a conditional:

while (true) {
        if (db_check_reconnect()) {
           ... do stuff
        } else {
                thold_daemon_debug('WARNING: No database connection.  Sleeping for 60 seconds.');

                sleep(60);
        }
}

Forgive me if I missed it, but reading the code of db_check_reconnect() in lib/databases.php it seems to me that this function does not ever return anything. Based on the little I know about PHP, if a function returns without an explicit return value then the implicit return value is NULL.

In which case this above conditional is if(null) which will always evaluate to false, causing thold_daemon to never actually do anything but complain about a lack of a database connection and sleep for 60 seconds.

To test this I changed the conditional to if (is_null(db_check_reconnect())) and thold_daemon now appears to be working. Is this a bug or did I jump the gun using the develop branch of thold in combination with the release version of Cacti 1.2.25?

@TheWitness
Copy link
Member

That's a big whoopsie.

@TheWitness TheWitness transferred this issue from Cacti/plugin_thold Dec 12, 2023
@TheWitness TheWitness added this to the 1.2.26 milestone Dec 12, 2023
@TheWitness TheWitness added bug Undesired behaviour confirmed Bug is confirm by dev team labels Dec 12, 2023
@TheWitness TheWitness changed the title thold_daemon always returns no database connection Function db_check_reconnect() does not properly return a value Dec 12, 2023
TheWitness added a commit that referenced this issue Dec 12, 2023
Function db_check_reconnect() does not properly return a value
@TheWitness
Copy link
Member

If you grab the latest lib/database.php from the 1.2.x branch of Cacti. This should be fixed now.

@TheWitness TheWitness added the resolved A fixed issue label Dec 12, 2023
TheWitness added a commit that referenced this issue Dec 12, 2023
Function db_check_reconnect() does not properly return a value
@eriksejr
Copy link
Contributor Author

Thanks, I have patched my database.php and so far so good on this front, though I hit an issue when thold tried to send some notifications overnight - I opened a new ticket about that under the thold plugin

@TheWitness
Copy link
Member

Okay cool.

@netniV netniV changed the title Function db_check_reconnect() does not properly return a value Database reconnection can cause errors to be reported incorrectly Dec 16, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Undesired behaviour confirmed Bug is confirm by dev team resolved A fixed issue
Projects
None yet
Development

No branches or pull requests

2 participants