Validate: Failed to fetch validation results

Help
1

Hi,

I recently installed LibreNMS (fresh) on a new Ubuntu installation and have started to populate it.

I was able to run validate from the GUI but recently it has stopped working, after a reboot I think.

When I run validate from the GUI I get the following error message:
image

If I run the command from the terminal I get an ‘OK’ response for everything:

===========================================
Component | Version
--------- | -------
LibreNMS  | 23.2.0-32-gca8b78049 (2023-03-14T17:42:45+00:00)
DB Schema | 2023_03_14_130653_migrate_empty_user_funcs_to_null (249)
PHP       | 8.1.2-1ubuntu2.11
Python    | 3.10.6
Database  | MariaDB 10.6.12-MariaDB-0ubuntu0.22.04.1
RRDTool   | 1.7.2
SNMP      | 5.9.1
===========================================

[OK]    Composer Version: 2.5.4
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQl and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service not detected
[OK]    Locks are functional
[OK]    Python poller wrapper is polling
[OK]    Redis is unavailable
[OK]    rrdtool version ok
[OK]    Connected to rrdcached

All services look happy. I can’t find anything in the log files and I have tried installing the requirements as per this page:

My browser is the latest version of Brave (v1.49.120), running on Windows 11.

Is there anything obvious that I might have missed?

2

Not the same php version for webserver and cli?

3

I’m not sure how to check?

4

on the cli you have PHP | 8.1.2-1ubuntu2.11
How to check the php version the webserver utilzes depends on your setup.

5

Is this what you meant?

php -version
PHP 8.1.2-1ubuntu2.11 (cli) (built: Feb 22 2023 22:56:18) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2-1ubuntu2.11, Copyright (c), by Zend Technologies
6

No, you already provided the php version the cli uses in you validate.
The possible problem is the php version your web server utilities as validate via browser fails.

7

Thanks. I carried out PHP checks from here:

As there’s no webserver hosting the files in the default WWW folder for NGINX I created the check php file in the LibreNMS WWW folder and ran it.
It came back with the same version number as the client.

8

If it works on the cli but not in the browser and you have the same php version in both then your problem is in the setting for the php variant as you probably have two under /etc/php/ one for the cli and one for the web. If the problem isn’t there it is most likely in the nginx config.

Also have a look into the logs that are configured in the above mentioned configs.

9

Well thanks for your help so far.

I checked and there’s only one php install under /etc/php:

ls /etc/php/
8.1

I didn’t see anything under the nginx.conf or conf.d that might be causing an issue.

I found this in the Nginx log file though:

2023/03/23 16:07:40 [error] 717#717: *46964 upstream timed out (110: Unknown error) while reading response header from upstream, client: IPADDRESSHERE, server: IPADDRESSHERE, request: "GET /validate/results HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm-librenms.sock", host: "IPADDRESSHERE", referrer: "http://IPADDRESSHERE/validate"

Which lead me to find the answer to this thread:

Which worked.

Is this pointing to a balance between time out and machine performance? (it’s an old ‘server’ that we’re using for this).
Should I report this as a “bug”?

1 Like
10

I don’t think that reporting this as a bug is necessary if your server is especially old and slow.
But then again, why not run it on a raspberry pi an save a lot of energy costs.

Yes, it’s a balance between time out and machine performance and also a protection against denial of service attacks.

On a internal server that doesn’t have hundreds of requests per hour, you can safely set this to minutes.

11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.