Issues with Weathermap Editor after auto Upgrade - Also Version shows year 1969

Randomly without making any changes, I have lost the ability to open editor.php for weathermaps within Librenms
the graphs continue to map properly.
Throughout poking around, not entirely sure but also looking at the version of LibreNMS, it indicates the version is from year 1969


Component Version
LibreNMS 1.49-97-g8ec2476
DB Schema 2019_02_10_220000_add_dates_to_fdb (132)
PHP 7.2.14
MySQL 5.5.60-MariaDB
RRDTool 1.4.8

[OK] Composer Version: 1.8.4
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct

It’s a known issue at the moment Not able to open Weathermap editor

Interesting find about the year!

Good to know about the open issue. didnt see that one when I searched yesterday. Thanks

any ideas on the Year? or if something else occured. or all part of the same issue perhaps?

I think that is just a build info bug, and unlikely to cause a problem. but i don’t have a daily version to test. See if it’s fixed tomorrow on the next build.

Will do, thank you
Will report back if issue persists

Looked into it a bit more, the version date is based off the git commit date,

So you should be able to track the commit with bad date here, but yes should cause no problem.


git log --format=fuller

Output from the above command:

commit 8ec247603613701f3687231d5f7f20e9d1f66cc6
Author: KodApa85 [email protected]
AuthorDate: Thu Mar 21 23:10:20 2019 +0000
Commit: PipoCanaja [email protected]
CommitDate: Fri Mar 22 00:10:20 2019 +0100

Added support for APC AP9810 zone contacts (#9967)

* device: Added support for APC AP9810 zone contacts

* fix: disconnected sensors been detected. And iemConfigProbesTable certainly does get used and it reference

* fix: load is VA, not to be confused with watts. This could be different per device though...
Apparent Power unit = VA
Real Power unit = Watts

And Keeping codeclimate happy

* feature: updated APC MIB

* feature: added test data for APC Smart UPS SMX750i and AP9810 with contact switches

commit 76597ea94a3459700f97d04ce1ccd11ddf584620
Author: Yann Gauteron [email protected]
AuthorDate: Thu Mar 21 08:52:01 2019 +0100
Commit: PipoCanaja [email protected]
CommitDate: Thu Mar 21 08:52:01 2019 +0100

Improving Health limits display (#10007)

commit fbfed49082b60cd4c5f7f32360f3f58338381bc5
Author: djamp42 [email protected]
AuthorDate: Thu Mar 21 03:51:14 2019 -0400
Commit: PipoCanaja [email protected]
CommitDate: Thu Mar 21 08:51:14 2019 +0100

Add Device Arris Apex (#10006)

* device arris-apex

* Code Climate Fixes

commit 96797aa813c3d183db80aedde7e4b49277379e4c
Author: Yann Gauteron [email protected]
AuthorDate: Wed Mar 20 16:17:49 2019 +0100
Commit: PipoCanaja [email protected]
CommitDate: Wed Mar 20 16:17:49 2019 +0100

Beautify port health (#9981)

* Removal of the unused  variable
* Replace double quotes by single quotes when possible
* Adding spaces between operands of the concatenation operator
* Rewrite of code echoed to the browser
* Reuse the logic of the Device/Health page for displaying current and limit values

Hmm that all looks fine, odd! System time is fine as well i take it?

system time is fine:

Fri Mar 22 14:50:27 GMT 2019

running in GMT

I also last evening attempted a reboot to see if it would clear the condition.
I am running RHEL 7, no change condition of date still showing remains

actually i just saw this in the validate config through the GUI.


Fail: DateTime::__construct(): Failed to parse time string (@) at position 0 (@): Unexpected character

Can you paste outputs

git status
git remote -v
git describe --tags
git show --pretty='%H|%ct' -s HEAD

git status

On branch master

nothing to commit, working directory clean

git remote -v
composer (fetch)
composer (push)
origin (fetch)
origin [email protected]:librenms/librenms.git (push)

git describe --tags

git show --pretty=’%H|%ct’ -s HEAD

Looks fine to me, 1553209820 is the unix timestamp for Thursday, March 21, 2019 11:10:20 PM

And the version should be getting the date from this, so not sure why it’s showing 1969 im afraid.

Super odd.
as you said there is another pull tomorrow right? so I will wait to see what version and code stream do to fix the weathermap issue and maybe clear up this date too

Yes your on the daily update schedule, so if there has been any changes to the project, then you will recieve them tomorrow.

You can check any changes here:✓&q=is%3Amerged

looks like after the weekend, the Weathermap is still not functioning and my version date is still showing 1969. I tried to run the and still did not force the update to show correctly.

Patch was pushed out to the master branch. And will be included in the release version.

Thank you,

I have ran into quite a serious issue that I am not sure how to get beyond
hoping for some help in the steps
so after hours of attempting to resolve 500 errors, I decided to revert back to a gold standard VM template I created
so this takes it back to version 1.48.1-98-g218b6b8
if i leave auto updates on, the daily script will run, grab a new version .(version escapes me) at that point the HTTP 500 errors come back. So then I go back to the drawing board
This system is in production, monitoring production hosts so pretty important, ideally moving to monthly stable releases is what I would prefer.
I followed this before:
To switch to using stable branches you can set $config['update_channel'] = 'release'; in config.php and then switch to the latest release branch with:
cd /opt/librenms && git fetch --tags && git checkout $(git describe --tags $(git rev-list --tags --max-count=1))

When i did this prior, it also broke items within my validation
for clarity, I am running RHEL 7 and Apache install.

Can someone help with the necessary steps that will allow me to move ahead, so that I can add devices again confidently without the 500 errors coming back

I should also note, that currently I have disabled auto updates by editing the config.php -

$config[‘update’] = 0; # uncomment to completely disable update