Jump to content

Cilusse

Members
  • Posts

    18
  • Joined

Posts posted by Cilusse

  1. I’ve been running @doron’s script for a few days and it has been perfect so far! Absolutely no unwanted spin ups, and my SAS drives are always sent to standby when needed.

     

    Thank you so much to everyone who contributed to this thread, especially @SimonF and @doron (and thanks for crediting me in your script even if I really just suggested something and haven’t written a single line of code 😆).

     

    Now let’s push this to the devs and get it included in Unraid!

    Stay safe and keep up the positive vibes 😉

    • Like 2
  2. 9 hours ago, doron said:

    I took some time to do a longer-running test, monitoring all my SAS drives every few seconds, to try and get a more comprehensive picture as to what's actually going on.

     

    Bottom line: The state 3 thing does work, and it spins down the drives, so that subsequent i/o wakes them up. However these SAS drives tend to spin back up for various other reasons, not all of which I can yet map. Indeed the periodical SMART instructions spins them up, but these aren't the only events causing that.

     

    I have a script that spins a SAS drive down when the syslog message about it is spewed by Unraid. I wrote an additional small script that looks for all SAS drives that should currently be spun down (aka greyed in the UI), and if they're not really spun down - spins them back down. I had it run immediately after the SMART query (you can do that with a "plugin EVENT"), to eliminate that cause, and kept the monitor running.

    What I found is that some of these drives keep spinning back up - after a few minutes or seconds - with no apparent reason (i.e. Unraid did not spin them up, and I don't see i/o being done against them). 

     

    At this time I don't have a good guess as to why this happens.

     @doron What is the best way to implement such scripts ? This reaches the limits of my Slackware knowledge 

    Thanks!

  3. My array consists of 4 SAS drives and 2 SSDs. At idle with only my background processes and the SSDs it’s using 40W, at idle with the SAS array unnecessarily spinning it uses 80W, and with the drives active and working, it’s around a 100W.

    I have a little current meter on my plug to measure and track energy usage and cost.

  4. This is awesome!

    The command:

    sg_start -vvv  --pc=3 /dev/sgX

    works perfectly with my SAS-only array.

    I've put it in a User Script running hourly to often make sure the drives are standing by, and whenever I access any files, the required drives spin back up!

    No errors to report so far and it's finally completely automatic !

     

    I really hope that Limetech can implement this behaviour in a future version of Unraid.

    Thank you so much for all the contributions, I love this community!

  5. I've been researching ways that might allow an automation of the sg_start command.

     

    iotop (available through NerdPack) can show real time read/write usage for any disks. This might not work because a spun down SAS drive will probably not show any activity as Unraid won't be able to access it.

     

    Then I came across ioping. This one is not available on NerdPack so I can't easily test it, but it logs the access latency to each drive. I am assuming that a spun down SAS drive will show an ever increasing latency until it fails and Unraid reports a read error in the array.

    There might be a way to write a script that looks at those latencies and spins a SAS drive up when it reaches a set threshold, just before Unraid fails the request and reports an error.

     

    Pair that to the syslog message that is sent when a drive un spun down by Unraid, and you have an almost automatic system to spin SAS drives up and down.

     

    If anyone has tinkered with those tools before, I would suggest to give it a try.

    What do you guys think ?

  6. I'm also showing my interest for such a feature to be implemented!

     

    The sg_start command works perfectly on my system.

    I also realised that the syslog shows when Unraid spins a drive down, there should be a way to tie the log entry and the sg_start command to follow Unraid's desire to spin a drive down.

    The syslog doesn't say when a drive is spun back up (or at least not with my current settings), but if it did, we would also have a way to trigger the SAS drives back up if this log entry is detected.

  7. Server name is 'und.ukb'. I actually changed that very recently, do you think the dot confuses the plugin as the name and certificate apparently don't match ?

     

    ...

     

    Just reverted to 'und' as name and the issue is fixed! So yes, the dot in the server name confuses the plugin somehow.

    Thank you for helping me resolve this!

  8. I tried to re-create the Unraid cert as you recommended and it didn't solve the problem.

     

    root@und:/boot/config/ssl/certs# ls
    controlr_cert.pem  controlr_key.pem  und_unraid_bundle.pem

    All of those certificate were re-created just now

     

    Console output is still the same.

  9. Hi,

    Thank you for your answer.

     

    Here's the console output when run from command line:

    I: 2020/07/21 20:07:58 app.go:58: controlr v2020.05.09|2.19.0 starting ...
    I: 2020/07/21 20:07:58 app.go:66: No config file specified. Using app defaults ...
    I: 2020/07/21 20:07:58 app.go:171: host(https://10.0.0.2:8443)
    I: 2020/07/21 20:07:58 core.go:81: starting service Core ...
    I: 2020/07/21 20:07:58 core.go:304: Created system sensor ...
    I: 2020/07/21 20:07:58 core.go:334: No ups detected ...
    I: 2020/07/21 20:07:58 server.go:92: Starting service Server ...
    I: 2020/07/21 20:07:58 server.go:111: Serving files from /usr/local/emhttp/plugins/controlr
    I: 2020/07/21 20:07:58 server.go:168: Server started listening http on :2378
    I: 2020/07/21 20:07:58 server.go:180: Server started listening https on :2379
    I: 2020/07/21 20:07:58 api.go:46: Starting service Api ...
    I: 2020/07/21 20:07:58 api.go:93: Api started listening https on :2382
    I: 2020/07/21 20:07:58 app.go:84: Press Ctrl+C to stop ...
    F: 2020/07/21 20:07:58 server.go:176: Unable to start https server: read /boot/config/ssl/certs: is a directory
     http server started on [::]:2378
     https server started on [::]:2382

    It looks like it doesn't like the certs location but I don't really understand why.

     

    The folder contains (along with the Unraid default certificate):

    root@und:/boot/config/ssl/certs# ls
    controlr_cert.pem  controlr_key.pem

     

    Hope this helps!

     

    All the best,

  10. Hi,

     

    I am having an issue with the plugin. ControlR can connect to my server just fine, but can't show logs and execute actions that necessitate the plugin.

     

    Plugin is installed, and when switched to ON, I can see the status changing to Running and then immediately reverting back to Stopped.

    I tried to re-install the plugin from CA, delete the config files, but it still won't start the service.

     

    The console outputs when starting the service.

    Jul 20 19:30:59 und ool www[6396]: /usr/local/emhttp/plugins/controlr/scripts/start
    Jul 20 19:30:59 und sudo:     root : TTY=unknown ; PWD=/usr/local/emhttp ; USER=root ; COMMAND=/usr/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' 

    The config file is pretty standard:

    SERVICE="enable"
    PORT="2378"
    CERTDIR="/boot/config/ssl/certs"
    UPS="disable"

     

    I also checked that no other web server is running on 2378 and it is definitely free to use.

    It used to work just fine a couple weeks ago, and I don't remember changing anything that can affect the plugin, other than normal and regular updates.

     

    Is there something wrong with my setup ? Is it a known issue ?

     

    Many thanks everyone!

×
×
  • Create New...