Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About kubed_zero

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. TLDR: 1. Clearer definition of Parity Check + "write corrections to parity disk" versus Parity check (read only), possibly with new naming 2. Documentation or a configurable setting that indicates whether a hard power off and the subsequent parity check on reboot is the read only or the read-write version 3. Parity History popup indicating status of "write corrections to parity disk" in previous runs ___________ I searched through the forums but couldn't find much on this. Basically, when we manually start a Parity check, there is an option to "Write corrections to parity." Without it, the Parity Check will run but not update the Parity drive with any discrepancies between the parity data and the data disks. That means that a Parity Check without the checkbox is more a Parity validation/check. When the checkbox is ticked though, the Parity drive will be rewritten in the event of any discrepancy between the data disks and the parity disks. For ease of reference, I'd love to see these terms clarified. Something that still holds the reverence of a full data read, but something that reflects that Parity disk data will be changed. I think Parity Check is still a fine term to be used for the read and diff to confirm there are no errors, and Rebuild is already taken in the Unraid universe when we need to get back the contents of a disk. Could a new term such as Parity Update or Parity Recompute or Parity Correction be used for instances of Parity runs where the checkbox is enabled? One other thing is that I'm not clear on what type of Parity Check is done on a power loss. Parity Check will start regardless at the next boot, but there's no setting or indication to make this behavior follow one option or the other. Finally, I wonder if it would be possible in the Parity history popup to have a new column that indicates whether or not the Parity disk was corrected to match the data disks. Looking at the history in its current form (or logs or anything else as far as I'm aware) there's no way to know what previous runs were configured as: with or without the "write corrections option" I hope this makes sense and am happy to revise or provide any more detail to submit this feature request for consideration! Alternatively, If I'm missing a feature already present in Unraid that would help me distinguish, please point me towards it. As mentioned I did a scan of the forums after coming up blank in the Web UI, but I could have missed it.
  2. Fantastic, glad things got sorted out. I'm a little surprised all the other logging was missing from the installation, I would have expected the notification that Perl was needed to show up when you were installing. Maybe it is different with Community Apps or something, not sure. Adding additional warning about Perl is a good suggestion, I'll look into adding it. Thanks!
  3. The PLG file executes in order, and since we see that the README is skipped over the next section with relevance is a bash script to check if Perl is installed: https://github.com/kubedzero/unraid-snmp/blob/master/snmp.plg#L119 I'm unclear as to why the error doesn't show up, but do you have NerdPack/Perl installed? root@UNRAID:~# which perl /usr/bin/perl root@UNRAID:~#
  4. Did you include the "exit 1" message in the logs you pasted?
  5. Yes. https://github.com/kubedzero/unraid-snmp/blob/master/snmp.plg#L102 the file is defined in the plugin and is skipped over if the file already exists (aka if the plugin is being upgraded or has been installed in the past) Here is my output from the syslog: Jun 6 14:09:10 UNRAID emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install /boot/snmp.plg Jun 6 14:09:10 UNRAID root: plugin: skipping: /usr/local/emhttp/plugins/snmp/README.md already exists Jun 6 14:09:10 UNRAID root: plugin: running: anonymous Jun 6 14:09:10 UNRAID root: plugin: skipping: /boot/config/plugins/snmp/libnl-1.1.4-x86_64-1.txz already exists Jun 6 14:09:10 UNRAID root: plugin: running: /boot/config/plugins/snmp/libnl-1.1.4-x86_64-1.txz Jun 6 14:09:10 UNRAID root: plugin: skipping: /boot/config/plugins/snmp/net-snmp-5.8-x86_64-5.txz already exists Jun 6 14:09:10 UNRAID root: plugin: running: /boot/config/plugins/snmp/net-snmp-5.8-x86_64-5.txz Jun 6 14:09:10 UNRAID root: plugin: skipping: /boot/config/plugins/snmp/snmp.png already exists Jun 6 14:09:10 UNRAID root: plugin: skipping: /boot/config/plugins/snmp/drive_temps.sh already exists Jun 6 14:09:10 UNRAID root: plugin: skipping: /boot/config/plugins/snmp/share_free_space.sh already exists Jun 6 14:09:10 UNRAID root: plugin: running: anonymous Jun 6 14:09:10 UNRAID root: plugin: skipping: /usr/local/emhttp/plugins/snmp/snmpd.conf already exists Jun 6 14:09:10 UNRAID root: plugin: running: anonymous Jun 6 14:09:11 UNRAID root: plugin: running: anonymous and here is output from the popup on the plugin page when I install /boot/snmp.plg (not using Github because it won't let you install the same version, so I had to edit the PLG to bump the version) plugin: installing: /boot/snmp.plg +============================================================================== | Skipping package libnl-1.1.4-x86_64-1 (already installed) +============================================================================== +============================================================================== | Skipping package net-snmp-5.8-x86_64-5 (already installed) +============================================================================== +============================================================================== | Copy files from /boot/config/plugins/snmp | into /usr/local/emhttp/plugins/snmp and set permissions +============================================================================== Copy complete! +============================================================================== | Updating /etc/rc.d/rc.snmpd to use our config file, and to reduce logging +============================================================================== Shutting down snmpd: . DONE Starting snmpd: /usr/sbin/snmpd -LF w /var/log/snmpd.log -LF w /var/log/snmpd.log -A -p /var/run/snmpd -a -c /usr/local/emhttp/plugins/snmp/snmpd.conf +============================================================================== | Testing SNMP by listing mounts, /boot should be present +============================================================================== Looks like snmpd is working... Output: HOST-RESOURCES-MIB::hrFSMountPoint.1 = STRING: "/mnt/disk1" HOST-RESOURCES-MIB::hrFSMountPoint.2 = STRING: "/mnt/disk2" HOST-RESOURCES-MIB::hrFSMountPoint.3 = STRING: "/mnt/disk3" HOST-RESOURCES-MIB::hrFSMountPoint.32 = STRING: "/dev/shm" HOST-RESOURCES-MIB::hrFSMountPoint.33 = STRING: "/var/log" HOST-RESOURCES-MIB::hrFSMountPoint.34 = STRING: "/boot" Here are how drive temperatures look: snmpwalk -v 2c localhost -c public NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp" NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp".1 = STRING: WDC_WD100EMAZ-00WJTA0_2YJ2ZUAD: 40 NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp".2 = STRING: WDC_WD100EMAZ-00WJTA0_JEG8PDSN: 42 NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp".3 = STRING: WDC_WD60PURX-64LZMY0_WD-WX21D84R1P9S: 33 NET-SNMP-EXTEND-MIB::nsExtendOutLine."disktemp".4 = STRING: WDC_WD60PURX-64LZMY0_WD-WX41D849PHH7: 32 Here is how share free space looks: snmpwalk -v 2c localhost -c public NET-SNMP-EXTEND-MIB::nsExtendOutLine."sharefree" NET-SNMP-EXTEND-MIB::nsExtendOutLine."sharefree".1 = STRING: Files: 1105516294144 NET-SNMP-EXTEND-MIB::nsExtendOutLine."sharefree".2 = STRING: John: 1105516294144 NET-SNMP-EXTEND-MIB::nsExtendOutLine."sharefree".3 = STRING: TMBackup: 564139593728 ----------------------------------------------------------- snmp has been installed. Version: 2020.04.01b ----------------------------------------------------------- plugin: installed DONE so I don't think that's a particular issue, and rather only shows that you've had SNMP installed in the past.
  6. Was there supposed to be an error in the log you posted?
  7. Does installing any other plugin work? https://www.reddit.com/r/unRAID/comments/c6kefi/rclone_on_unraid/ and https://forums.unraid.net/topic/72238-unraid-updates-failing/ both mention the same issue and the cause being issues with RAM, issues with the USB, or general, non-SNMP-specific problems. Can you paste the logs from when you're trying to install after making sure you have sufficient RAM free, sufficient USB space free, and have rebooted the server?
  8. Did you try restarting the server? Did you try reinstalling the plugin? What version of the plugin are you using? What version of Unraid are you using? The curl command on localhost would have no impact on the functionality of SNMP, as I believe SNMP uses some port other than port 80 to communicate. As you can see, the curl command redirects you to the Dashboard and is using Nginx which is more relevant to the Unraid GUI than to SNMP.
  9. That is in theory possible. Unraid has the following to commands available. The first lists out the overall speed and the second lists speed of each core I guess. The second would be more difficult to parse and add as output since there would need to be a per-core to speed mapping (2x the OIDs as there are cores) but both are theoretically possible. myuser@mysys:~# lscpu | grep "CPU MHz" CPU MHz: 2400.000 myuser@mysys:~# cat /proc/cpuinfo | grep "cpu MHz" cpu MHz : 2400.000 cpu MHz : 2400.000 cpu MHz : 2400.000 cpu MHz : 2400.000 That said, I am not sure how well this translates to other generations of CPU or different manufacturers. I'm running an Intel CPU under ESXi and Unraid is in a VM at the moment. I have no idea how general the script would need to be to work for everyone installing this. If you check out my previous comment you can see how to easily make a shell script and integrate it into your SNMP config to get the values printed out for yourself.
  10. Does it register/overwrite the SNMP configuration when it's installed? Otherwise I don't think it will have OIDs show up. If you wanted it to show up you'd have to make a shell script that outputs the values you want and then add it to the snmp.conf in the same way as disktemp and sharefree are added: https://github.com/kubedzero/unraid-snmp/blob/master/snmp.plg#L225 That config file would be in /usr/local/emhttp/plugins/snmp/snmp.conf. I think you'd then have to kill and restart SNMP to get the changes to show up. If you wanted this to persist between reboots you'd have to modify the Go file or modify a local copy of the SNMP PLG file to have the changes you want.
  11. You'll have better luck actually reading the snmpwalk man page https://helpmanual.io/help/snmpwalk/, but from your Unraid console running snmpwalk -v 2c localhost -c public will print out all MIBs and their current values. For my system that's 4046 values. Then you can use the link/command I sent earlier to output a specific MIB that you want to see.
  12. I see, I don't think the MIBs are listed anywhere but an snmpwalk command should list everything out for you. The original author of this plugin also added a couple extended MIBs for getting the disk temperatures and free Unraid Share space. Here's the example of the MIB for the extensions https://github.com/kubedzero/unraid-snmp/blob/master/snmp.plg#L269 https://github.com/kubedzero/unraid-snmp/blob/master/snmp.plg#L274
  13. There are no settings to adjust in the GUI, you could check on the PLG file to see how it's configured and how the config file is generated and then make edits yourself. What do you want to find the settings for?
  14. I'll have to look into that. Thanks for the advice! The .txz file would then be cached on the USB and unzipped into /usr/local/emhttp/plugins? Do you have any recommended repos that install in this fashion? I would still be interested in an answer to my original question if anyone can provide: What documentation is out there for the allowed XML tags in a .plg file that would tell us input and output, allowed tags, etc.
  15. All installed plugins reinstall automatically every boot, since /usr/local/emhttp does not persist between reboots since it lives in RAM. I've made an optimization that downloads this plugin's files first to the persistent USB storage and then copies the files into the working directory in RAM. That means once this update is applied, until the files' MD5 sums change the reinstall on each reboot will use the already-downloaded copy. The code change has been pushed https://github.com/kubedzero/unraid-snmp/commit/6d4d8a77e4c44e827b19f9814fab5b7debfa90b9 and should be available for users to update. Let me know if you have questions or suggestions!