kubed_zero

@griffinite you could use this without the plugin needing to change at all. Save it to /boot/ and then you can add a line in the SNMP settings on the Settings page such as extend networking /boot/networkinfo.sh Long time no see @irishjd thank you for the contribution!

You are welcome to write a Bash script that collects network data and submit a pull request if you want to share the work with others. That's how CPU, Memory, Disk data is currently collected https://github.com/kubedzero/unraid-snmp/blob/main/source/usr/local/emhttp/plugins/snmp/cpu_mhz.sh

I think at present, the best way is to cancel the parity CHECK that runs after an unsafe shutdown ASAP and start a parity CORRECT. Or as you said, do the work twice: identify the errors in the first run and then correct the errors in a full second pass.

Run `ps -aux | grep snmp` to see if the service is still running. The output I saw was `root 3273 0.0 0.0 22748 7160 ? S Jan15 0:19 /usr/sbin/snmpd -A -p /var/run/snmpd -LF 0-5 /var/log/snmpd.log -c /etc/snmp/snmpd.conf` That clues you in to the next place to look, /var/log/snmpd.log. My log file is empty but maybe yours has a clue You could also check /var/log/syslog to see what's there. The last snmp line I see in mine is "rc.local: plugin: snmp.plg installed" You could also share your Diagnostic file, found under Tools/Diagnostics

I mean, that sounds to me as if whatever your backup process is is impacting the SNMP plugin. Can you share more about the backup process? What's running, what's backing up, where is it backing up, how is it scheduled, what software, etc.

I haven't seen this behavior before so I'm not sure what could be causing it. I suspect it's some other plugin/docker/script on your server but I can't say for sure. To eliminate SNMP itself as the cause, you should uninstall the plugin, reboot, and reinstall it. Uninstalling removes all the files and should fully reset its configuration.

See my response from a while back. Alternatively, feel free to add a pull request that adds switching logic and support for both versions of Unraid. The open-vm-tools plugin could provide a template for how to do this.

The reason I suggested this was that the error message said the /boot mount point can only be found. That's the USB drive that Unraid boots off of but does not actually operate off of. I suspect there was some issue where the boot device got disconnected or unplugged or something. The SNMP plugin uses the statistics from the /boot device to make sure everything is working OK. Anyway, glad to hear it's working!

What version of Unraid are you running? Can you reboot and try to reinstall the plugin?

Yeah, the way Unraid is doing updates, the plugin is in a weird state where it only works with a single version at a time. If you want to try this, I'm fully supportive. Otherwise, install the 6.x version with https://github.com/kubedzero/unraid-snmp/raw/refs/heads/eol/snmp.plg or the 7.x version with https://raw.githubusercontent.com/kubedzero/unraid-snmp/refs/heads/main/snmp.plg

Correct. You'll have to reinstall anyway because the current version will break when upgrading to v7 due to the removed SSL library in the new version, moving it into the "install errors" plugin folder. It would have been nice to have a release of Unraid with both versions so there could be a transition period, but alas. It's possible to do some switching on the Unraid version number and install different package versions based on the Unraid OS version, but I'm not able to work on that right now. Feel free to submit a pull request if you want! It shouldn't be too bad, the open-vm-tools plugin does something similar. Some switching logic that could install one set of plugins for Unraid 6.x and one set of plugins for Unraid 7.x

@opticon see what I wrote just above your message:

All right @dgaglioni I've updated the plugin to support v7, the trick was to update the SNMP and Perl library dependencies to the latest version. I suspect this will break compatibility with Unraid v6 as it only comes bundled with SSLV1 while Unraid v7 comes with SSLV3, so I've set the minimum version of the update to 7.0.0-beta.1. As always, it can be downloaded from https://github.com/kubedzero/unraid-snmp/raw/refs/heads/main/snmp.plg For those that don't plan to upgrade to v7 and don't want to see the "Update Available" notification that will never succeed due to the old Unraid version, I have an end-of-life branch that can be used instead of the main branch: https://github.com/kubedzero/unraid-snmp/raw/refs/heads/eol/snmp.plg. It was previously pinned to the last release supporting Unraid 6.9.3, but now supports 6.11.0 to 6.12.13

I haven't tried building or running this on 7.x yet but I'll take a look when I have some time and cap the existing version and then release a new version if it's needed. Thanks for reporting this! The libssl.so.1.1 error is related to SSL v1 not being found, probably because Unraid 7 uses SSL v3 now.

How were these compiled, or where did these builds come from? Last I checked, there weren't public Slackware or Unraid SlackBuild files or precompiled TXZ files around. I looked through your Github repo https://github.com/desertwitch/python-unRAID but didn't see build information in there, just the compiled TXZs