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

You could run `pip3 install urllib3` manually, or in the go file: https://github.com/urllib3/urllib3?tab=readme-ov-file#installing

All right friends, here are updated files for Python 3.12.5 (with bundled Pip 24.2), Borg 1.4.0, and PyFUSE 3.3.0 (same version as last time but I recompiled). All were built and tested on Unraid 6.12.13, plus tested on 7.0.0-beta.2. I confirmed Python started up and ran some basic tests, I confirmed Pip could download and update packages, and I confirmed Borg could make new repos and mount previous backups with FUSE. I ended up using the same package versions as last time, as many updated versions were giving me GLIBC-2.38 errors, as Unraid 6.x uses GLIBC-2.37 (and Linux 6.1.x). For example, trying to use OpenSSL-3.3.1 instead of 3.1.1 caused this error to crop up when trying to use wget. Thankfully Unraid 7.x seems to use GLIBC-2.39 (and Linux 6.8.x) so I suspect the issue will go away once 7.x is live. Unraid 7.x also bundles OpenSSL-3.3.1 so I suspect up-to-date versions of all packages will be able to be used next time, at the expense of dropping Unraid 6.x compatibility. Another update is that Borg 1.4.0 no longer bundles liblz4, libstd, or libxxhash https://github.com/borgbackup/borg/pull/8117 but the documentation said it did https://borgbackup.readthedocs.io/en/stable/installation.html#dependencies. There is now a bug report to get this fixed https://github.com/borgbackup/borg/issues/8342 I compiled Python 3.12.5 with the following packages (some not needed for Python compilation itself, but needed to exist on the system afterwards for the Pip compilation of pyfuse3 and borgbackup): acl-2.3.1-x86_64-1.txz attr-2.5.2-x86_64-1.txz binutils-2.41-x86_64-1.txz bzip2-1.0.8-x86_64-3.txz expat-2.5.0-x86_64-1.txz fuse3-3.15.0-x86_64-1.txz fuse3-3.16.2-x86_64-1.txz gc-8.2.4-x86_64-1.txz gcc-13.2.0-x86_64-1.txz gcc-g++-13.2.0-x86_64-1.txz gdbm-1.23-x86_64-1.txz git-2.43.0-x86_64-1.txz glibc-2.37-x86_64-2.txz guile-3.0.9-x86_64-1.txz kernel-headers-6.1.64-x86-1.txz libffi-3.4.4-x86_64-1.txz libmpc-1.3.1-x86_64-1.txz libzip-1.10.1-x86_64-1.txz lz4-1.10.0-x86_64-1.txz lzlib-1.13-x86_64-1.txz make-4.4.1-x86_64-1.txz ncurses-6.5-x86_64-1.txz openssl-3.1.1-x86_64-1.txz openssl-solibs-3.1.1-x86_64-1.txz openssl11-1.1.1w-x86_64-1.txz openssl11-solibs-1.1.1w-x86_64-1.txz pkg-config-0.29.2-x86_64-4.txz readline-8.2.001-x86_64-1.txz xxHash-0.8.2-x86_64-1.txz xz-5.4.3-x86_64-1.txz zlib-1.2.13-x86_64-1.txz zstd-1.5.6-x86_64-1.txz The end of the compilation spit out the following summary: The following modules are *disabled* in configure script: _ctypes_test _sqlite3 _testbuffer _testcapi _testclinic _testimportmultiple _testinternalcapi _testmultiphase _xxtestfuzz xxsubtype The necessary bits to build these optional modules were not found: _dbm _tkinter _uuid nis To find the necessary bits, look in configure.ac and config.log. Checked 110 modules (31 built-in, 64 shared, 1 n/a on linux-x86_64, 10 disabled, 4 missing, 0 failed on import) Then I worked on pyfuse3 and borgbackup compilation, a much simpler process than Python (one line each!): I confirmed pyfuse3 worked with the following dependency versions: attrs-24.2.0 idna-3.8 outcome-1.3.0.post0 pyfuse3-3.3.0 sniffio-1.3.1 sortedcontainers-2.4.0 trio-0.26.2 I confirmed borgbackup worked with the following dependency versions: msgpack-1.0.8 packaging-24.1 All my Python use cases seem to be working, but let me know if any issues are encountered. Don't forget to add OpenSSL-3.1.1 to the /boot/extra/ directory alongside the Python package! It's attached, or you can download from https://slackware.uk/search?p=%2F&q=openssl-3.1.1-x86_64-1.txz python3-3.12.5-x86_64-1-kubed20240825.txz borgbackup-1.4.0-cp312-cp312-linux_x86_64.whl pyfuse3-3.3.0-cp312-cp312-linux_x86_64.whl openssl-3.1.1-x86_64-1.txz

Well no, because now you have Docker is running on the NAS. Now Unraid has to deal with things such as VLANs and networking, persistent storage outside the array, resource sharing, and a whole other slew of factors. I don't mess with anything other than a parity drive and a few data drives, and Docker would add unnecessary complication. That's fine though, we are all entitled to use Unraid how we want. Again, I'm sharing the work I did on my own system, everyone's free to use it or free to ignore.

Or just use a fresh trial copy of the latest version of Unraid to build the packages in the first place! This is my technique at least. That way I'm also able to check against the latest stable versus beta version without too much effort. I disagree strongly, but we're all welcome to our own opinions for each of our own use cases. Here is my hot take, in my opinion Unraid should be purely a NAS OS and not the hypervisor Docker flash-drive-backed extravaganza it's become. I want my NAS to focus purely on safely storing the files within. In my use case I run Unraid as a VM and use Python only for NAS-related stuff, aka Borgbackup. Borg needs 3.10 or newer, and I'm not running Beta Unraid in prod just to get 3.11, so I need to update the system version of Python to a later version. At the time I started this off, 3.9.x was literally the latest slackware-compatible version I could find on the internet, so compiling itself was the only choice I had. I am happy to see there are more options available to folks now, but disappointed 3.12.x Slackware/Unraid builds are not more widely available. This wasn't available at the time I needed it, and it's still not tracking the latest major version of Python, 3.12.x (released LAST YEAR). Especially given these big updates improve system-related features and performance, running a new version is very important to me. All that said, I still think this self-compilation path is the best option I've got unless someone beats me to it and shares a TXZ file or the official files are kept more up to date. Given the recent thread activity, I might even be sparked into building the new versions in the next few weeks! 😃 This was a good prompt, I looked more closely at your GitHub Gist and the ensurepip flag is interesting, I might check that out in the next round of development. Same thing with the suggestion for /var/lib/pkgtools/packages, what a nice summary of everything that's installed! My current 6.12.8 Unraid installation seems to have glibc-2.37-x86_64-2 installed

I agree, somewhat. If there are officially built versions of the *latest* Python (which as of writing is 3.12.5) and Borg (1.4.0) I'd happily skip the compliation steps and just use those. As far as I've seen that hasn't been available, so I've been stuck compiling them for my own use and sharing them in case others run into the same issue as me. I share the instructions though in case my files aren't trusted, so anyone can perform the same steps as me to get their own packages

Yes, that's right. I built pip into my package because I needed Unraid to get a later version of Python and Pip up and running *without internet* and therefore needed Pip and the Pip packages to install while the internet was still unavailable. I need to review my notes but either just running the pip update command may be possible, OR it might be necessary to install the build dependencies to recompile the Wheel file that Pip can then install. Better than using an even older version that is generally available? Borg is doing its big 2.0 update *soon* so I'm waiting for that to redo all the compilation stuff. At that point I'll probably do the latest 1.x and the latest 2.x release and offer both packages I opted to just compile on Unraid itself as it's then guaranteed to operate the same on the machine doing compliation and the machine running just the compiled packages 😃

I have a build of Python + Pip + Borg and instructions here if nothing else ends up working. I'm using it successfully on 6.12.8 right now.

The Settings>SNMP page allows you to modify the configuration. You can also edit it directly at /etc/snmp/snmpd.conf (though this will not persist between reboots). See my Github repo for more details https://github.com/kubedzero/unraid-snmp/tree/main

To clarify on this: Unraid has the ability to install arbitrary .txz packages automatically at boot, anything in the /boot/extra/ directory will be installed. Furthermore, the terminal command `installpkg path/to/package.txz` can also be used to install packages. I still use this plugin's Github page as a repository to download packages https://github.com/UnRAIDES/unRAID-NerdTools/tree/main/packages/6.11 but I also use https://slackware.uk/slackware/slackware64-current/ as a source. Sometimes I find that packages need to be built manually as well, such as Python, which I have a thread for over at So in essence, many people asking for plugins just need to find Slackware-comatible versions online, download them to their boxes, and then run the install command. There may be other methods as well, such as a package manager similar to apt/yum/dnf/homebrew or a similar GUI, but at the end of the day downloading to your box and running an install command are all these options are doing. Also, it's safe to say this is a lie and an excuse to abandon the project. There's been minimal support on this which I called out over six months ago when trying to get my Python change merged. It still isn't merged 🙃 https://github.com/UnRAIDES/unRAID-NerdTools/pull/84

Thanks for checking! No problem, feel free to use it.