kubed_zero

Ah, I found the true root cause of everyone's issue. https://linux.die.net/man/8/snmpd notes the different flags. Looking more closely at the output from ps, I see the default settings for snmpd are to call with the -a flag which "Logs the source addresses of incoming requests" hence the huge log files. [email protected]:~# ps -ef | grep snmp root 2070 1 0 18:54 ? 00:00:00 /usr/sbin/snmpd -A -p /var/run/snmpd -a -c /etc/snmp/snmpd.conf root 2933 2715 0 18:55 pts/0 00:00:00 grep snmp So the root cause is twofold: I didn't have the doinst.sh script built in a way that was compatible with SNMP 5.9.3, and this allowed the default flag to log all addresses and fill up people's disks. This is fixed in the version I just released, 2023.04.20 (blaze it). https://github.com/kubedzero/unraid-snmp/releases/tag/2023.04.20 Now the ps output should look the same as what I have below: [email protected]:~# ps -ef | grep snmp root 4749 1 0 19:20 ? 00:00:00 /usr/sbin/snmpd -A -p /var/run/snmpd -LF 0-5 /var/log/snmpd.log -c /etc/snmp/snmpd.conf root 5247 5167 0 19:21 pts/0 00:00:00 grep snmp One can also verify the correct behavior by looking at the update log output in the plugin update popup window. This is wrong, because the desired flags don't match the actual flags: Editing SNMP startup options in rc.snmpd to be [-LF 0-5 /var/log/snmpd.log -A -p /var/run/snmpd -a] Restart SNMP daemon now that we've adjusted how rc.snmpd starts it Starting snmpd: /usr/sbin/snmpd -A -p /var/run/snmpd -a -c /etc/snmp/snmpd.conf This is the correct output: Writing extra SNMPD_OPTIONS into /etc/default/snmpd to configure logging Start SNMP daemon back up now that snmpd.conf and /etc/default/snmpd modifications are done Starting snmpd: /usr/sbin/snmpd -A -p /var/run/snmpd -LF 0-5 /var/log/snmpd.log -c /etc/snmp/snmpd.conf Thanks all and let me know if you have issues!

OK, I've figured out the issue and will have a fix out soon. The newest version of the SNMP plugin (2023.02.19) declares a dependency on net-snmp-5.9.3-x86_64-1.txz. Meanwhile the old version (2021.05.21) uses net-snmp-5.9-x86_64-1.txz. The problem is that the net-snmp package differs in its /etc/rc.d/rc.snmpd file from 5.9 to 5.9.3, so the do-inst.sh file in my own unraid-snmp plugin fails to modify the file to adjust the logging. Old /etc/rc.d/rc.snmpd snippet: OPTIONS="-A -p /var/run/snmpd -a" start() { if [ -x /usr/sbin/snmpd -a -f /etc/snmp/snmpd.conf ]; then echo -n "Starting snmpd: " /usr/sbin/snmpd $OPTIONS -c /etc/snmp/snmpd.conf echo " /usr/sbin/snmpd $OPTIONS -c /etc/snmp/snmpd.conf" fi } New /etc/rc.d/rc.snmpd snippet: [ -r /etc/default/snmpd ] && . /etc/default/snmpd SNMPD_OPTIONS=${SNMPD_OPTIONS:-"-A -p /var/run/snmpd -a"} start() { if [ -x /usr/sbin/snmpd -a -f /etc/snmp/snmpd.conf ]; then echo -n "Starting snmpd: " /usr/sbin/snmpd $SNMPD_OPTIONS -c /etc/snmp/snmpd.conf echo " /usr/sbin/snmpd $SNMPD_OPTIONS -c /etc/snmp/snmpd.conf" fi } My modification code, compatible with 5.9 but not 5.9.3: new_flags="-LF 0-5 /var/log/snmpd.log " options=$(grep "OPTIONS=" /etc/rc.d/rc.snmpd | cut -d'"' -f 2) if [[ $options != *"-L"* ]]; then options=$new_flags$options echo "Editing SNMP startup options in rc.snmpd to be [$options]" sed --in-place=.bak --expression "s|^OPTIONS=.*|OPTIONS=\"$options\"|" /etc/rc.d/rc.snmpd else echo "SNMP logging flag already present in rc.snmpd, skipping modification" fi I need to change this code to something that can handle the new syntax. Some thoughts I'll be exploring: I saw /etc/default/snmpd included in the new SNMP package but not the old, and perhaps that could be used I need to check the syntax, but I might be able to just set an environment variable SNMPD_OPTIONS as the install script now seems to merge whatever it's set to with the values declared in /etc/rc.d/rc.snmpd I could update my script to just do the text modification inside the /etc/rc.d/rc.snmpd file, the same as it was before but with updated find and replace logic Hopefully I'll have a plugin update out in the next week. Thanks @Uncore for the details!

You didn't need to do this, I explicitly noted this in an earlier message: anyway... Odd. I'm running 6.9.2 and have no issues: [email protected]:~# cat /etc/rc.d/rc.snmpd #!/bin/sh # # rc.snmpd This shell script takes care of starting and stopping # the net-snmp SNMP daemon OPTIONS="-LF 0-5 /var/log/snmpd.log -A -p /var/run/snmpd -a" [email protected]:~# ps -ef | grep snmp root 3744 1 0 Apr15 ? 00:01:35 /usr/sbin/snmpd -LF 0-5 /var/log/snmpd.log -A -p /var/run/snmpd -a -c /etc/snmp/snmpd.conf root 19665 19643 0 17:33 pts/0 00:00:00 grep snmp Yes, this is expected. A clean install of SNMP would be: - Uninstall SNMP plugin, and ensure it fully completes and removes all the SNMP-related files in /boot/config/plugins - Reboot Unraid - Reinstall SNMP after reboot That's great news. That means the issue people are seeing seems to be from SNMP's logging modification not installing properly. Again, odd that I can't reproduce this and haven't seen this myself. What version of Unraid?

Still no luck. I tried the following on 6.12-rc3 with macOS 13.3.1. I added these settings to /boot/config/smb-fruit.conf and did an array stop and start each time. I checked /etc/samba/smb-shares.conf to confirm the settings were applied each time. No luck, from vfs objects = acl_xattr fruit streams_xattr fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes No luck, from vfs objects = catia fruit streams_xattr fruit:encoding = native fruit:metadata = stream fruit:posix_rename = yes No luck, from https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X vfs objects = fruit streams_xattr fruit:metadata = stream fruit:model = MacSamba fruit:posix_rename = yes fruit:veto_appledouble = no fruit:nfs_aces = no fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes In all cases, I can't mount the sparsebundle, the Time Machine backup does not complete, etc. Back to 6.9.2 🤦‍♀️ Edit: One more note, since I only saw one comment on this that I now can't find. https://www.samba.org/samba/security/CVE-2021-44142.html versions of Samba prior to 4.13.17 had a vulnerability if the use of vfs_fruit and fruit:metadata=netatalk or fruit:resource=file. Considering 6.9.2 used Samba 4.12.14, it was affected by this, and it's possible the fix has affected functionality.

So more people are having this issue, odd. What's in your logs, the same thing as @irishjd? We were chatting in PMs, but I guess this applicable to more people. I've never had luck with log output. - What version of Unraid are you using? - Did you apply any customizations to the SNMP config? - Have you rebooted recently? - Has uninstalling and reinstalling the SNMP plugin made any difference? I suspect I know the line that is causing this. Inside the unraid-snmp TXZ file there is the do-inst.sh script that configures and modifies everything. Specifically, there is a line that sets up the logging https://github.com/kubedzero/unraid-snmp/blob/main/source/install/doinst.sh#L58 Right now it outputs levels 1=a=alert, 2=c=crit, 3=e=err, 4=w=warn, 5=n=notice into /var/log/snmpd.log. I'd suspect that changing this line to output something else (0-4, 1-4, 1-3, etc) would probably cut down on your log output. That said I've never gotten ANYTHING to show up in /var/log/snmpd.log on my own installations so I've never been able to test. I need reproduction steps to get a better idea of what's happening.

What is it filled with? The file has always been empty whenever I checked or did development on it.

I stand by my decision to stick with 6.9.2 until the DEFAULT settings for Unraid's SMB configs work correctly for the BUILT-IN functionality of Time Machine. 6.9.2 did that just fine, and there's no valid excuse in my mind for 6.11 and onwards to not include it. Especially given people have been able to hack their way to something functional. I still challenge Unraid to raise the bar and get Time Machine backups working by default on a fresh install of 6.11/6.12 with zero additional manual config necessary. AKA: - Install Unraid to a flash drive - Boot, create a one disk no-parity array - Create a Time Machine compatible share after enabling macOS optimization in the SMB settings - Perform a successful backup - Perform successful incremental backups (which is the part that I've not yet seen working correctly) Bonus points if Time Machine shares created on 6.9 and earlier can continue to work with 6.11 and onwards.

Thanks for that info @MVLP. I realized I could optimize the way I'm grabbing CPU MHz so I applied that change and stopped using cat, hopefully it won't happen anymore. @cjhammel I also added the change to read the Community string from the snmpd.conf file, so changing the Community should no longer fail the SNMP plugin installation after boot. These changes are a part of 2023.02.19 😄

Thanks all for the info. I just released an update 2023.02.18 that should fix this, now reading from /proc/cpuinfo instead of lscpu. I found during testing Unraid 6.12 that my VMs with an updated version of lscpu (2.38 vs 2.36) were no longer outputting CPU MHz at all, much less min and max. Granted, my implementation only reads the speed of CPU core 0, but I figure that's better than nothing. Technically someone could submit a PR that grabs the CPU MHz from all the different cores and averages them out, or gets the max (or min) from all of them. Let me know how install/update and testing goes @[email protected] @irishjd

Thanks for sharing, what a beast of a CPU! I'll be interested in seeing what @MVLP posts as well. If it's the same, I might have to modify the script to attempt to grab "CPU max MHz" if "CPU MHz" doesn't output anything.

CPU speed is manually fetched with a shell script that calls `lscpu` and then parses the results. https://github.com/kubedzero/unraid-snmp/blob/main/source/usr/local/emhttp/plugins/snmp/cpu_mhz.sh#L11 Can you run `lscpu` and share the results with me, either here or by PM? I should be able to modify the script to parse other lines if your system (and others' too I imagine) uses a different way to post CPU speed.

I added this info to the Recommended post for this topic, but a good debugging step is to do a sanity check that SNMP is fully removed from the OS (not from the boot drive) by running `removepkg net-snmp unraid-snmp`. @iball used this to get back to a good state, without the need for a reboot! I have no plans to change the default at the moment. You can also use the Settings->SNMP page to modify the SNMP configuration. One of the lines by default is `rocommunity public` which I assume is the change you're looking for. Be warned that the plugin install script (the PLG file at /boot/config/plugins/snmp.plg) expects certain config values such as the "public" community, and may require modification. You're also welcome to make a PR that automatically picks up the community name from the SNMP config, that functionality is not yet built in.

Simple Network Management Protocol (SNMP) is a widely used protocol for monitoring the health and welfare of electronics. This Unraid plugin installs and configures SNMP for basic use with tools such as Observium and Grafana. This Unraid plugin assists with installing SNMP and its dependencies and then configuring them for Unraid. For example, it adds extensions into SNMP to output Unraid Share and disk size, disk temperature, memory usage, and CPU speed. Install Link (6.11 and newer): https://raw.githubusercontent.com/kubedzero/unraid-snmp/main/snmp.plg Install Link (6.7 thru 6.10.3): https://raw.githubusercontent.com/kubedzero/unraid-snmp/14cf6e875860526a25148bd86c2f812bbfddb590/snmp.plg Unraid 6.10.3 and older use older versions of libc/glibc (2.33 in 6.10.3, 2.30 in 6.9.2), and the latest versions of net-snmp and perl require libc-2.34 and newer. GitHub: https://github.com/kubedzero/unraid-snmp Other notes: Instructions for building and/or contributing features can be found in the GitHub repo's README There is a Settings page for users to tweak the SNMP configuration to their liking. Be warned that the plugin install script expects certain config values, and may also require modification depending on the changes to the SNMP config (such as the Community, permissions, etc.) Good to know debugging: If you don't want to reboot and are experiencing install issues, perhaps it's because Unraid thinks the package is already installed. Run `removepkg net-snmp unraid-snmp` to uninstall them if they're installed (it will do nothing otherwise). You can also run `rm -rf /boot/config/plugins/snmp/` to remove the plugin install directory from the USB drive, wiping out any customizations. Both of these steps are performed when uninstalling the plugin through Unraid's UI.

I'm still on 6.9.2 and all is still working fine here with macOS Ventura 13.1. Now that 6.11.5 is out I might try upgrading and giving it a shot at some point.

Right on. The install script does a sanity check to ensure it's working correctly, and fiddling with the snmpd.conf file can absolutely get it in a state where the install script no longer works. I can't think of a good way of validating the install was successful while also allowing for custom snmpd.conf files. For those adventurous enough to modify the config, I'm hoping they're also confident in editing the PLG to disable the sanity test and allow installs to proceed. And also as you noted, if one gets into a bad state, deleting the SNMP files from /boot and rebooting would be a surefire way of starting from scratch. The logs posted by @dgaglioni showing "unraid-snmp-2021.05.21-x86_64-1 (already installed)" indicates that this was not a fresh install.