bland328

tl;dr: It appears to me that Unraid 6.9.2 doesn't honor device-specific temperature notification settings for Unassigned Devices for a straightforward reason that is easily fixed. Now that I have two unassigned NVME drives in my Unraid server, the annoyance of over-temp notifications that ignore the per-device settings has doubled, so I've come up with what is hopefully a true fix, rather than a workaround, in the form of a small change to the check_temp function in /usr/local/emhttp/plugins/dynamix/scripts/monitor. Here's the diff for /usr/local/emhttp/plugins/dynamix/scripts/monitor in Unraid 6.9.2: 61,62c61,66 < global $notify,$disks,$saved,$display,$server,$top; < $disk = &$disks[$name]; --- > global $notify,$disks,$devs,$saved,$display,$server,$top; > if (isset($disks[$name])) { > $disk = &$disks[$name]; > } else { > $disk = &$devs[$name]; > } The logic behind the change is that it appears to me that while the $devs array does properly include the hotTemp ("Warning disk temperature threshold") and maxTemp ("Critical disk temperature threshold") values as a result of CustomMerge.php merging them from the /boot/config/smart-one.cfg file, the check_temp function in 6.9.2 fails to consider the $devs array at all. This patch changes check_temp so that $devs is included as a global, so that if the passed $name can't be found in the $disks array, a lookup in $devs can be attempted, instead. I suspect there's a more elegant way to implement the fallback from $disks to $devs, but I'll leave that as an exercise for people who know PHP well I don't claim this to be well-researched or production-quality code, but it does fundamentally make sense, and It Works On My System™, so I hope this is helpful.

Problem description Under Unraid 6.9.2, mover appears to leave symbolic link files targeting non-existent files ("broken" symlink files) in the cache forever. Though such symlinks are commonly called "broken" or "invalid" symlinks, those titles are a bit misleading; in truth, though they "feel" weird, they are perfectly legitimate file system objects with a variety of purposes and reasons for existing, so I hope/assume this is simply a bug and/or oversight in mover. How to reproduce Simply make a symlink to an invalid path in a user share that uses the cache, like this... # ln -s /foo/bar /mnt/user/test/symlink ...then start the mover, and check to see if the symlink file has been moved to the array. Notes I see this both on a mature production server and on a newer box that still has a close-to-vanilla configuration; the attached diagnostics are from the latter. Before capturing diagnostics, I turned mover logging on and started mover to test against a /mnt/user/test/test_symlink file. I see "/mnt/cache/test/test_symlink No such file or directory" appears in the syslog, which may be a clue as to the bug causing this: broken symlink files are peculiar in that some methods of testing for existence fail because the symlink's target file doesn't exist (because the symlink is being "followed"). Here's an example of what I mean, in hopes it helps: root@Tower:/mnt/user/test# ls -la test_symlink lrwxrwxrwx 1 root root 18 Apr 28 08:21 test_symlink -> /invalid/test/path root@Tower:/mnt/user/test# [[ -e test_symlink ]] && echo "exists" || echo "does not exist" does not exist root@Tower:/mnt/user/test# [[ -L test_symlink ]] && echo "exists" || echo "does not exist" exists protekto-diagnostics-20210428-1027.zip