doron

Community Developer
  • Posts

    524
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by doron

  1. Actually that command is supposed to spin a drive back up. I suggested you try it once the state you described occurs.
  2. Okay. In general, this thread is for support of the plugin. This is the infamous 04h/11h status. When the issue happens, you may want to try sg_start -rp1 /dev/sdX and see if it helps.
  3. Have you been using the SAS Spindown plugin?
  4. After some more testing with @greg0986over PM, turns out the issues stem from their Unraid being at a low version. Some binaries the plugin depends on were not installed before version 6.7.0. Plugin updated (v0.84 pushed out yesterday) to require Unraid 6.7.0 as minimum. Thanks @greg0986for the help in this.
  5. Okay two different things. Re the NVME - unrelated to the plugin. You want to specify spindown delay of "never" for those, or Unraid will try to spin them down (as you saw) and fail. Re the other thing (Child terminated), will try to figure this out.
  6. So now you didn't get the "child terminated" message?!
  7. This might indicate a problem in the syslog hook used to trigger spindown in versions below 6.9. - Can you indicate which version of the plugin is installed? - Are you getting any "SAS Assist" messages in your syslog? - Can you do this, from the Unraid CLI: touch /tmp/spindownsas-debug and then try to spin down a SAS drive and paste the resulting syslog excerpt? After doing that you can just rm /tmp/spindownsas-debug To stop the debug messages.
  8. Thanks for reporting. Do you see any "SAS Assist" messages in the log? Indeed.
  9. This is in fact applicable to all 6.x versions including stable, just thought it'd be nice if it could be fixed in 6.9 (small effort). Issue: Any filter (or other rsyslog script) you deposit in /etc/rsyslog.d/ does not affect the local syslog files. It does affect remote syslog streams, if configured(*). Reason: /etc/rsyslog.conf, as configured by the webGui scripts, looks like this (excerpt): (...) $Umask 0022 # # Include all config files in /etc/rsyslog.d/ # limetech - ok # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # limetech - everything goes to syslog. $RuleSet local *.debug -/var/log/syslog (...) Note that the "$IncludeConfig" directive precedes the "$RuleSet local" directive. This means that when files from /etc/rsyslog.d/ are included, they are applied within the applicable default RuleSet at that moment - "RSYSLOG_DefaultRuleset". The net result is that under the "local" ruleset, the filters are not applied. If the user configures a remote syslog facility, then another section is added to rsyslog.conf, with "$RuleSet remote", within which the content of /etc/rsyslog.d/ is read again(!), so the filters are applied on remote syslog, but not local. Solution: Place the "$RuleSet local" directive above the "$IncludeConfig /etc/rsyslog.d/*.conf" directive. This needs to be fixed in the Dynamix script (syslog setting UI), since the vanilla Unraid /etc/rsyslog.conf seems to not contain $RuleSet directives at all. Sample patch to /etc/local/emhttp/webGui/scripts/rsyslog_config: --- rsyslog_config 2021-01-09 19:02:20.528996624 +0200 +++ rsyslog_config-n 2021-01-09 19:58:06.434929884 +0200 @@ -14,7 +14,7 @@ # create local ruleset if ! grep -q '^\$RuleSet local$' $ETC; then - sed -ri '/^# limetech - everything goes to syslog.$/a$RuleSet local' $ETC + sed -ri '/^# Include all config files/a$RuleSet local' $ETC sed -ri '/^#?\*\.\* @@?.*:[0-9]+$/a$DefaultRuleset local' $ETC fi (*) Actually, the instantiation is a bit more complex: This issue is created only if the user has, at any time, used the Settings/Syslog Server dialog. As distributed, the Unraid /etc/rsyslog.conf does not have a RuleSet configured, so does not have the issue.
  10. I'm not asking that, I'm sure you did. I presume your current situation is that you CAN start the array when typing the passphrase at the GUI, but can not change it using cryptsetup and / or my script. Is my understanding correct? Can you tell me what types of characters are in your passphrase? Not asking to share the phrase obviously, just the type of characters it is comprised of: - Does it have non Alphanumeric characters? - Does it have non-ASCII characters (i.e. from a code page different than Latin)? If so can you give an example of such a character? (again do not reveal your real phrase, just the nature of the characters in it) EDIT: Can you PM me a passphrase that is LIKE yours in terms of character set? Again, not even close to your real one, just something that I can test with, and that is structured similarly to the passphrase you're having an issue with.
  11. Both, and anyone else who is looking to change the LUKS passphrase of their HDDs... 🙂
  12. A slightly simpler way to get what you want might be: 1. Write a short script that just prints the password ("echo mygoodpassword"). Assume you put it at /root/mypass. 2. In /boot/config/go, add: DISPLAY=: SSH_ASKPASS=/root/mypass setsid ssh -N -R 8000:XX.XX.XX.XX:8000 root@XX.XX.XX.XX
  13. Sorry, that was my bad. I forgot you're at 6.8.3 (I'm too deep into 6.9 already). Yeah, 6.9 does this for UD as well. Not sure it's gonna help much, given that your drives refuse spin down 🙂 Very helpful. It's an almost definitive testimonial that these Seagates with this controller would not spin down.
  14. Ah. This might make the testing somewhat less accurate. If the drives are active during the test (with real data moving, or even just filesystem housekeeping), that activity might spin the drive back up while you're waiting between setting and testing. I presume the plugin is installed? You'd not see a "SAS Assist" message if you fiddle with the drives manually. You should see it if, instead, you'd hit the green button next to one of your SAS drives (that are under UD), to cause the drive to spin down. Have you tried that? Do you see a SAS Assist message then? If you do try that, and the GUI does show a grey ball, then chances are it's spun down properly - you can double check with the sense command (without doing the sg_start thing). Thanks for posting! See my first comment above. If you want to further test, you may want to edit the sas-util script, remove (or comment out) the one line that says "sleep 3s" and try again. I'd be curious to see the results. EDIT: Alternatively, you can just try this: sg_start -rp3 /dev/sdb && sdparm -C sense /dev/sdb and show the results.
  15. Thanks for the kind words. What we've been seeing is kind of hit and miss, so no strict verdict re a certain series of HDDs; you may want to just try. Re the specific issue, some of the Seagate documentation seems to imply that power mode 3 (the mode we're setting the drive into) is implemented as needing an explicit command to spin the drive back up. This does not jive too well with how Unraid is expecting things to behave (basically, it is expected that a subsequent i/o to the drive will implicitly spin it back up). Bottom line, you may want to give it a try and see. You can also use the provided sas-util (bundled with the plugin at /usr/local/emhttp/plugins/sas-spindown/sas-util, or you can take it from here), with the parameter "test", to try and predict how things will work. (Unfortunately, even this test is not 100% accurate - I have at least one happy camper whose SAS drives merrily spin down and up with the plugin, but still fail the test...). If you do, please post (or pm) the resulting file. Happy 2021!
  16. Thanks for reporting - that's good to hear. If you could also run: /usr/local/emhttp/plugins/sas-spindown/sas-util and send over the resulting file (pm me or post), that'd be great.
  17. Sure is... Check out the output file (or see below). Thanks for your help! "controller": { "Slot": "01:00.0", "Class": "Serial Attached SCSI controller [0107]", "Vendor": "Broadcom / LSI [1000]", "Device": "SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] [0064]", "SVendor": "Broadcom / LSI [1000]", "SDevice": "9200-16e 6Gb/s SAS/SATA PCIe x8 External HBA [3030]", "Rev": "02"
  18. Thanks for reporting! I'm really happy to hear that. Would you mind running /usr/local/emhttp/plugins/sas-spindown/sas-util and send me the resulting file (/tmp/sas-util-out)? (when run without parameters it doesn't do anything intrusive, just reports the HDD and controller(s) models in JSON format) You can pm me or post here (no sensitive info such as serial numbers etc. is shared). Thanks
  19. Posting in this thread just to follow up, I've just pushed a new version (0.8) of the SAS Spindown plugin, supporting 6.9.0-rc1 and the new spin up/down mechanisms. It's on CA.
  20. I've just pushed a new version - 0.8 - of the plugin, supporting 6.9.0-rc1 and its new spin up/down mechanisms. As always, please report issues.
  21. @SimonF, a new version of the SAS spindown plugin is coming shortly, supporting 6.9.0.
  22. Thanks for doing that. That's great news. Unraid (in kernel upto 6.8 and in userspace in the future) looks at i/o activity to determine spin up of a drive.
  23. Thanks for reporting! Happy to hear it worked well for you.
  24. This is essentially what the plugin does when it tries to spin down SAS drives. So either this does nothing in your setup (combination of hard drive and controller), or something else is going on. Could it be that you have constant i/o against the array - in which case, a spun-down drive will immediately spin back up? Do you see i/o counters (read or write) on the main page moving, during that time?