'Operating System' field not updated


It’s come to my attention that the ‘Operating System’ field for devices is never updated, except for with one device. For example, one device used ‘Linux 4.19.0-16-amd64 (Debian GNU/Linux 10)’ on its first discovery, but has been on ‘Linux 5.10.0-15-amd64 (Debian GNU/Linux 11)’ for 2 months.

This field did update for one device that was upgraded about 20 minutes ago after I ran the poller
manually (although it might have updated by itself; I don’t know if the poller ran before I ran it manually after upgrading the device). This is the only exception. I’m not sure what’s different about this device.

Looking in the code, I see that the polling for the os module is done in the poll function in LibreNMS/Modules/Os.php. Code: https://github.com/librenms/librenms/blob/22.8.0/LibreNMS/Modules/Os.php#L53

The if ($os instanceof OSPolling) branch is false. LibreNMS checks if files exist in includes/polling/os/, but the only file in there is vmware-esxi.inc.php, so I assume that’s somewhat deprecated. Those branches are also false. Finally, we end up in the branch that outputs echo "Generic :(\n"; and the value of the fields that should be updated is set as follows:

$deviceModel->version = ($version ?? $deviceModel->version) ?: null;
$deviceModel->hardware = ($hardware ?? $deviceModel->hardware) ?: null;
$deviceModel->features = ($features ?? $deviceModel->features) ?: null;
$deviceModel->serial = ($serial ?? $deviceModel->serial) ?: null;

None of these variables are set in Os.php or in vmware-esxi.inc.php, so I assume we’re looking for globals. Printing these:

printf('version is %s', $deviceModel->version);
printf('version is %s', $version);

… yields:

version is 4.19.0-18-amd64
version is 

So, the null coalescing operator ($version ?? $deviceModel->version) returns the second operand $deviceModel->version (4.19.0-18-amd64). The ternary operator evaluates to the left operator, so $deviceModel->version is $deviceModel->version, i.e. it’s unchanged.

The poller module outputs:

#### Load poller module os ####

Generic :(

SQL[select * from `locations` where `locations`.`id` = ? limit 1 [2] 0.19ms] 

Location: Cyberfusion

Hardware: QEMU Standard PC (i440FX + PIIX, 1996)

OS Version: 4.19.0-18-amd64

OS Features: Debian GNU/Linux 10

Serial: Not Specified

>> Runtime for poller module 'os': 0.0018 seconds with 181024 bytes

>> SNMP: [0/0.00s] MySQL: [1/0.00s]   

It also seems counter-intuitive odd that OS version is set to 4.19.0-18-amd64 (that’s the kernel) and OS features is set to Debian GNU/Linux 10 (that’s the OS version). Is this intended behaviour?

Any hints?

validate.php output:

Component | Version
--------- | -------
LibreNMS  | 22.8.0-133-g0f14a7c17
DB Schema | 2022_07_19_081224_plugins_unique_index (244)
PHP       | 7.4.30
Python    | 3.7.3
Database  | MariaDB 10.6.9-MariaDB-1:10.6.9+maria~deb10-log
RRDTool   | 1.7.1
SNMP      | 5.7.3

[OK]    Composer Version: 2.4.1
[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 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
[WARN]  Your install is over 24 hours out of date, last update: Tue, 23 Aug 2022 22:24:35 +0000
	Make sure your daily.sh cron is running and run ./daily.sh by hand to see if there are any errors.
[WARN]  Your local git contains modified files, this could prevent automatic updates.
	You can fix this with ./scripts/github-remove
	Modified Files:

The legacy code set these fields in polling, current code sets them in discovery, because they do not change every 5 minutes…
The globals are from legacy polling code can probably be removed now that all code has been ported. Those global vars should never exist in polling.

Basically, you need to look at discovery, not polling.

Yes, it is intended that os = linux, version=kernel version, features = distro+distro version

Hi Tony,

On GitHub, you wrote:

When the snmpextend output changes, so does the data in the database.

This is the output of the extend:

. = INTEGER: 1
. = STRING: "/usr/bin/distro"
. = ""
. = ""
. = INTEGER: 5
. = INTEGER: 1
. = INTEGER: 1
. = INTEGER: 4
. = INTEGER: 1
. = STRING: "Debian GNU/Linux 11"
. = STRING: "Debian GNU/Linux 11"
. = INTEGER: 1
. = INTEGER: 0
. = STRING: "Debian GNU/Linux 11"

As you can see, ‘Debian GNU/Linux 11’ is returned. However, the ‘featureset’ in LibreNMS is set to ‘Debian GNU/Linux 10’.

Should I use a different OID?

Yeah, I thought you were talking about in discovery then. But I found out you were talking about polling later, which I addressed here.

That is the legacy snmp extend in your snmpd.conf.


Check here shows the modern snmp extend as shown in the docs. Followed by the two legacy (pre-fork) OIDs.

That should still work, I wonder why it isn’t falling back to it. Could be some quirk due to your configuration or a bug.

Any chance you could share ./discovery.php -d -m os -h <hostname> output? It should show why.

On one device, I replaced the pre-fork SNMP extend:

extend . distro /usr/bin/distro

… with the ‘modern’ one from SNMP Configuration Examples - LibreNMS Docs

extend distro /usr/bin/distro

… and ran discovery manually. That updated the ‘Operating System’ field.

I just changed the snmpd config line on another device, and will wait for discovery to run by itself to see if the issue is permanently solved. I will report back.

Thanks for the hint! Unfortunately, the pre-fork SNMP extend is still to be found all over over the internet …

I just changed the snmpd config line on another device, and will wait for discovery to run by itself to see if the issue is permanently solved. I will report back.

The issue has been permanently solved.

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

Perhaps yet another fallback oid needs to be added then.