Bizzarre Daily Behavior - Global Config Resetting

[Ziranthium]

Every day my global config settings are “resetting”. I noticied this when I suddently stopped receiving email alerts. When I checked the alert setting they had been modified to something completely invalid (the “from email address” had switched to the VM name). I tried several times to correct the settings, but each time I left and returned to the alert settings page, they were invalid again.

Here is an outline of my steps:

• Updated alert settings to the correct settings
• Returned to Dashboard
• Returend to alert settings : everything was once again invalid
• Ran “Validate Config” from the UI : validation indicated the “base URL could be more specific”
• Checked the alert settings : still invalid
• Ran “Validate Config” again : everything passed (base URL message was gone)
• Checked the alert settings : settings were correct
• The next day, alerts were not coming through
• Checked the alert settings : Invalid settings
• Ran “Validate Config” : first time it shows the base URL warning
• Ran “Validate Config” again : warning is gone, everything passed
• Checked the alert settings : settings are correct.

I have to run through this every day, sometimes twice. I cannot, for the life of me, figure out why the settings don’t stick. I did notice that it’s NOT just the alert settings that reset, some of the WebUI settings also reset daily and magically fix themselves when I run “Validate Config”.

Screenshots of the WebUI are attached.
Here is the output of validate.php:

PHP Deprecated:  Carbon\CarbonTimeZone::toOffsetName(): Implicitly marking parameter $date as nullable is deprecated, the explicit nullable type must be used instead in /opt/librenms/vendor/nesbot/carbon/src/Carbon/CarbonTimeZone.php on line 158
PHP Deprecated:  Carbon\CarbonTimeZone::toOffsetTimeZone(): Implicitly marking parameter $date as nullable is deprecated, the explicit nullable type must be used instead in /opt/librenms/vendor/nesbot/carbon/src/Carbon/CarbonTimeZone.php on line 172
PHP Deprecated:  Carbon\CarbonTimeZone::toRegionName(): Implicitly marking parameter $date as nullable is deprecated, the explicit nullable type must be used instead in /opt/librenms/vendor/nesbot/carbon/src/Carbon/CarbonTimeZone.php on line 188
PHP Deprecated:  Carbon\CarbonTimeZone::toRegionTimeZone(): Implicitly marking parameter $date as nullable is deprecated, the explicit nullable type must be used instead in /opt/librenms/vendor/nesbot/carbon/src/Carbon/CarbonTimeZone.php on line 230
===========================================
Component | Version
--------- | -------
LibreNMS  | 25.1.0-56-g962e828f6 (2025-01-29T21:43:47-05:00)
DB Schema | 2025_01_28_135558_ports_drop_unique_ifindex (313)
PHP       | 8.4.1
Python    | 3.10.12
Database  | MariaDB 10.6.18-MariaDB-0ubuntu0.22.04.1
RRDTool   | 1.7.2
SNMP      | 5.9.1
===========================================

[OK]    Composer Version: 2.8.5
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[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]    rrd_dir is writable
[OK]    rrdtool version ok

If anyone has any clue or could at least point me in the right direction, I would appreciate the assist. Thanks!

[Whiskey-Water]

Good day - I am getting the same error message. Tried the “Fix” and it actually changes it from WARN to FAILURE. So I would not encourage people to do the “Fix” at this time.
I would really like to hear a way to fix this also.
librenms@librenms:~$ ./validate.php

Component	Version
LibreNMS	25.1.0-69-gd2a7c6f81 (2025-01-31T10:09:42-06:00)
DB Schema	2025_01_30_000121_add_ifindex_index_to_ports_table (314)
PHP	8.3.16
Python	3.10.12
Database	MariaDB 10.6.18-MariaDB-0ubuntu0.22.04.1
RRDTool	1.7.2
SNMP	5.9.1
===========================================

[OK] Composer Version: 2.8.5
[OK] Dependencies up-to-date.
[OK] Database connection successful
[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] Distributed Polling setting is enabled globally
[OK] Connected to rrdcached
[OK] Active pollers found
[OK] Dispatcher Service is enabled
[OK] Locks are functional
[OK] Python wrapper cron entry is not present
[OK] Redis is functional
[OK] rrdtool version ok
[OK] Connected to rrdcached
librenms@librenms:~$

[Ziranthium]

@Whiskey-Water I see you’re getting the same Base URL error, but are you also seeing that your Global settings require a “reset” multiple times per day?

Also, what “fix” are you referring to? My post does not contain any recommendations to solve any of my issues, it’s simply an outline of the steps I’ve taken and the results they’ve produced. All in the hopes that someone far smarter than me can point me in the right direction.

Personally, I don’t care about the URL warning, I’m more concerned that I can’t get reliable alerts.

[Whiskey-Water]

Apologies, I was referring to hopefully someone has a fix.

I am not having the email resets just the URL error like yourself.

[Ziranthium]

Ahhh. Thanks for the clarification.

[Ziranthium]

I did some more digging yesterday and noticed my server was running PHP8.4.1.

After downgrading to PHP8.3 and verifying permissions on all the installation directories via (Installing LibreNMS - LibreNMS Docs), my issues are all resolved…

• I’m no longer getting the BaseURL error
• Alerts are working
• The Web UI config settings no longer “reset” after a few hours

It seems like PHP8.4 created all my issues.

Hopefully, this helps someone else.