Looking for better ideas how how to sleep/suspend my unraid box

I put my notes on getting sleep and wake on lan working in the wiki under the 'How-Tos' section.  This way the smart people can go in and make edits and hopefully make it more useful. 

Link: http://lime-technology.com/wiki/index.php/Setup_Sleep_%28S3%29_and_Wake_on_Lan_%28WOL%29

In the notes, I reference my batch file for sending the magic packet and also my s3.sh file that is called from the 'go' script.  Copies of those files are attached to this post.

Hope there's something useful in there for someone. 

AGW

Good notes. Hopefully one day I'll be able to use them

BTW, on step 6, I am pretty sure you have to spin down the drives before sleeping or you will always end up with a parity check on resume.

AGW - Thx for the write-up.  Much appreciated.

I put my notes on getting sleep and wake on lan working in the wiki under the 'How-Tos' section.  This way the smart people can go in and make edits and hopefully make it more useful. 

 

Link: http://lime-technology.com/wiki/index.php/Setup_Sleep_%28S3%29_and_Wake_on_Lan_%28WOL%29

 

In the notes, I reference my batch file for sending the magic packet and also my s3.sh file that is called from the 'go' script.  Copies of those files are attached to this post.

 

Hope there's something useful in there for someone. 

 

AGW

 

The script for automatic sleep works like a charm on my system. Only my Intel Pro 1000 GT (PCI) does not wake up the system, although WOL is enabled. The onboard RTL8169 works on that department, but fails in most others ;-). Know how to switch eth0 with eth1?

Just tired beta 4.5.7 with the new kernel and my system still doesn't wake by magic packet. I have to manually press the power button. After waking, I see my NIC is still getting reset to wake on: d. It is set to g before I send the sleep command. Is there something going on during the process it does before sleeping that is causing this to happen? I've read some posts around the net where people are modifying certain files such as rc.local.

> Unfortunately, the WOL kept getting reset after each reboot, so we put

> "ethtool -s eth0 wol g" at the end of /etc/rc.local, which fixed that

> problem. A few dozen reboots of various boxes assured us that this

> bandaid is holding.

You could use /etc/rc.local or some system boot scripts, but this wouldn't be the best way to do it. On startup your network interfaces are configured, sure, but there are other times when your network interfaces may be brought up or down and you will need this executed during those times.

 

You want to edit /etc/network/interfaces:

 

You should have a line like:

 

iface eth0 inet static

 

Underneath that, indented further, you want to create a post-up and post-down commands e.g.

 

iface eth0 inet static

    post-up /usr/sbin/ethtool -s eth0 wol g

    post-down /usr/sbin/ethtool -s eth0 wol g

 

Obviously, replace eth0 with the relevant interface if different.

Does either of these have any bearing here?

Oddly enough I also noticed if I set eth0 to wake on "pumbg", after I wake it manually it will be set on "pumb", the g goes away.

I was able to get S3 sleep working on my new unRAID box quickly, thanks to agw's wiki and the info I found here. So I thought I had everything working the way I wanted... that is until I experienced a couple of incidents where unRAID went to sleep while serving music to my media player!

I believe the problem is that my RAM buffer (I have 2 GB installed) is able to store more music than will play in the time period I have set before the hard drives spin down + the delay I have set in the S3.SH script.

Obviously one solution is to significantly increase the time periods so that they exceed the maximum amount of "play time" the cache will hold. (Can anyone tell me approximately how much of my 2GB is dedicated to buffering?) But I suspect this would mean the server would stay awake a lot longer than would otherwise be necessary in the vast majority of circumstances.

I think the optimal solution would be to modify the S3 script to check to see if there is any network activity going on before implementing the sleep state.

Do you think I have diagnosed the problem correctly?

Can anyone suggest how to change the script to accomplish what I describe?

Thanks!

I've got this working fine on my unRAID box (props to OMV & agw ), but I too am suffering from my NIC coming back from sleep running only at 100Mbps speeds, not gigabit speeds.

I'm wondering whether it's possible to force the NIC to gigabit using

ethtool -s eth0 speed 1000

I can't access my unRAID box at the moment, but I might give a go over the weekend.

If it works (and it really is as simple as that), then should it just be a case of inserting the line into the post-sleep section of OMV's script?

I'll let you know how I get on...

I still have the same issue - please post back if you have any break throughs!  System negotiates a gigabit connection on boot, but then every subsequent wake from S3 comes back at 100Mbps.  I can telnet in and set back to 1000Mbps using ethtool - but I've not tried to automate it using the sleep script - not sure that's going to be successful.

agw

I still have the same issue - please post back if you have any break throughs!  System negotiates a gigabit connection on boot, but then every subsequent wake from S3 comes back at 100Mbps.  I can telnet in and set back to 1000Mbps using ethtool - but I've not tried to automate it using the sleep script - not sure that's going to be successful.

Have you guys tried upgrading to the latest unRAID beta? 4.5 beta 7

I ask because, just possibly, the latest Linux kernel may have better drivers for your network controller.

I have had similar experiences with the gigabit network adapters (Marvel) on two of my motherboards not renegotiating 1000Mbps on S3 wake-up under Windows Vista. Eventually driver upgrades solved the problems. The Marvel adapter on my unRAID board was one of the troubleprone ones. It now works fine with unRAID 4.5 beta 6.

Another possibility is a marginally compliant cable. I've seen that as well, with both CAT 5e and CAT 6 cables that usually worked fine at 1000Mbps from a cold boot but sometimes still prevented the network adapter from negotiating 1000Mbps on S3 wake-up. Might be worth experimenting with another cable.

Now could anyone please lend a hand with my questions, three posts up?

I was able to get S3 sleep working on my new unRAID box quickly, thanks to agw's wiki and the info I found here. So I thought I had everything working the way I wanted... that is until I experienced a couple of incidents where unRAID went to sleep while serving music to my media player!

 

I believe the problem is that my RAM buffer (I have 2 GB installed) is able to store more music than will play in the time period I have set before the hard drives spin down + the delay I have set in the S3.SH script.

 

Obviously one solution is to significantly increase the time periods so that they exceed the maximum amount of "play time" the cache will hold. (Can anyone tell me approximately how much of my 2GB is dedicated to buffering?) But I suspect this would mean the server would stay awake a lot longer than would otherwise be necessary in the vast majority of circumstances.

 

I think the optimal solution would be to modify the S3 script to check to see if there is any network activity going on before implementing the sleep state.

 

Do you think I have diagnosed the problem correctly?

 

Can anyone suggest how to change the script to accomplish what I describe?

 

Thanks!

The S3 script already checks, if all disks are spun down.

I have added checks if the HTPC-machines are up and available (powered on) - so Unraid doesn't go to sleep as long as the HTPCs are running - even if the disks are spun down. Can be done easily e.g. with ping and works fine.

Disadvantage: Unraid will never go to S3 if HTPC is running, even if HTPC is not using it.

The S3 script already checks, if all disks are spun down.

I have added checks if the HTPC-machines are up and available (powered on) - so Unraid doesn't go to sleep as long as the HTPCs are running - even if the disks are spun down. Can be done easily e.g. with ping and works fine.

Disadvantage: Unraid will never go to S3 if HTPC is running, even if HTPC is not using it.

Yes. I understand the script checks if all disks are spun down. In my case, unRAID disks have all spun down, though there is still music qued in the RAM cache and being transmitted to my media player at the time the unRAID box goes to sleep.

I'm not entirely clear if what you are stating relates to my situation... I don't have an HTPC. I am using a WDTV as my media player (though essentially that amounts to a Linux "PC").

If I understand correctly, you are saying that your script is already checking with pings to determine if any device is receiving traffic from the unRAID server?

If so, then there appears to be a problem in my case. Thanks for any clarification or thoughts you might add.

Maybe the smbstatus program can be used to reveal open files and/orlocks on the smb share.

Maybe the smbstatus program can be used to reveal open files and/orlocks on the smb share.

Sorry. You guys are far... far ahead of me when it comes to Linux, which is to say that I don't know enough about Linux to write a competent script on my own.

Rereading Guzzi's post and looking at the S3.SH script that I am using from awg's wiki, I now understand that Guzzi is refering to modifications he made on his script to check whether his HTPCs were on, and not to the basic script I am using.

So Guzzi, if you would be kind enough to share your code I would like to give it a try.

[edit]If all the added code does is ping the client for a response, I don't think it will help with the WDTV, because the WDTV does not power off completely. It only "soft-offs" so the network controller remains on. You can even telnet and FTP to it while it's in the "off" state.[/edit]

And, WeeboTech, if you could illustrate how to incorporate your idea into the script I would also appreciate it. Though, please note, I am using NFS shares not smb, so maybe it wouldn't help in my case.

My apologies for being at the beginning of the learning curve on this stuff and relatively useless at helping myself.

Any help would be appreciated.

Maybe the smbstatus program can be used to reveal open files and/orlocks on the smb share.

 

Sorry. You guys are far... far ahead of me when it comes to Linux, which is to say that I don't know enough about Linux to write a competent script on my own.

 

Rereading Guzzi's post and looking at the S3.SH script that I am using from awg's wiki, I now understand that Guzzi is refering to modifications he made on his script to check whether his HTPCs were on, and not to the basic script I am using.

 

So Guzzi, if you would be kind enough to share your code I would like to give it a try.

 

[edit]If all the added code does is ping the client for a response, I don't think it will help with the WDTV, because the WDTV does not power off completely. It only "soft-offs" so the network controller remains on. You can even telnet and FTP to it while it's in the "off" state.[/edit]

 

And, WeeboTech, if you could illustrate how to incorporate your idea into the script I would also appreciate it. Though, please note, I am using NFS shares not smb, so maybe it wouldn't help in my case.

 

My apologies for being at the beginning of the learning curve on this stuff and relatively useless at helping myself.

 

Any help would be appreciated.

ok, in fact my script is useless for you, if your networkdevice keeps TCP up while "switched off" - it works fine for devices that enter e.g. S3 mode - so, the networkadapter is active and responds on MAC address, but TCP-stack is not running, so it's NOT responding to a ping.

For sure I am not good in scriptingstuff, so my script is not elegant, but it does what I need... here is what I added as "check":

    ping "DNSNameOfDevice or IP-Address" -c 1 | grep -q "ttl="

    if [ $? -eq 0 ]

    then

echo HTPC is active

    else

echo HTPC is not active

    fi

One more question from my side - I read somewhere, that it is possible not to spin up the harddrives when waking up the unraid machine from S3 - has anybody successfully done this? To my understanding at least the devices need some reinitialization that usually causes the drives to spin up. Or is this depending on the mobo/BIOS?

I still have the same issue - please post back if you have any break throughs!  System negotiates a gigabit connection on boot, but then every subsequent wake from S3 comes back at 100Mbps.  I can telnet in and set back to 1000Mbps using ethtool - but I've not tried to automate it using the sleep script - not sure that's going to be successful.

 

agw

Well, I can say that it works 100% of the time, but I did upgrade to 4.5b7 at the same time, so now I'm not sure which method was successful...

I'll do some more playing, but in the meantime, here's the modified s3.sh script I'm using - one simple addition to the wake-up section:

#!/bin/bash
drives="/dev/sda /dev/sdb /dev/hda /dev/hdb"
timeout=5
count=5
while [ 1 ]
do
hdparm -C $drives | grep -q active
if [ $? -eq 1 ]
then
  count=$[$count-1]
else
  count=$timeout
fi
if [ $count -le 0 ]
then
  # Do pre-sleep activities
  sleep 5
  # Go to sleep
  echo 3 > /proc/acpi/sleep
  # Do post-sleep activities
  # Force NIC to use gigabit networking
  ethtool -s eth0 speed 1000
  # Force a DHCP renewal (shouldn't be used for static-ip boxes)
  /sbin/dhcpcd -n
  sleep 5
  count=$timeout
fi
# Wait a minute
# echo COUNT $count
sleep 60
done

Adding the same command  'ethtool -s eth0 speed 1000' to the post-sleep section of the script seems to be working for me also.  I've only done a handful of wake-ups since yesterday, but previously the reduced network speed happened 100% of the time after the first boot.  So it seems to be a good fix.  Good idea Fibblebot.

I've been running 4.5beta7 - it did not fix the s3 problem for me.

EDIT: THIS VERSION SEEMS TO RESET THE USB CONNECTION TO THE unRAID FLASH DRIVE; THIS FILLS UP THE syslog; SEE NEXT POST

Here's a version of the sleep script that counts how many SATA devices are active. It does not require customization to fit what HDDs you have or what they are called. It also doesn't care whether a SATA device is part of the array, is being preclear'd, or similar.

* If you have only PATA devices, do "for d in /dev/hd?".

* If you have both SATA and PATA, do "for d in /dev/sd? /dev/hd?".

NB! The script relies on the flash drive answering "unknown" to "hdparm -C", i.e., on the flash drive never being "active". I'm not sure whether that's always the case for all flash drives. If not, several different modifications will work, the simplest (and ugliest) being to check for "[ $awake -eq 1 ]".

<deleted>

superseded by http://lime-technology.com/forum/index.php?topic=3657.msg41767#msg41767

Same principle and goals as above, but now we specify the device id, /dev/sdX, of the flash drive, to avoid hdparm'ing it.

NB! Maybe someone could contribute some script magic to automatically extract the device id of the flash drive from unRAID ...

<deleted>

superseded by http://lime-technology.com/forum/index.php?topic=3657.msg41767#msg41767

Here's a version of the sleep script that counts how many SATA devices are active. It does not require customization to fit what HDDs you have or what they are called. It also doesn't care whether a SATA device is part of the array, is being preclear'd, or similar...

Seems to be an elegant concept. Agree that "perfection" would require code to automatically identify and exclude the flash drive. (And - in my own case - check for absence of network traffic before sleeping.)

Maybe someone could contribute some script magic to automatically extract the device id of the flash drive from unRAID ...

Try this:

flash=/dev/`ls -l /dev/disk/by-label| grep UNRAID | cut -d"/" -f3`

echo $flash

It will grab the device with the UNRAID label and assign it to the variable named "flash" as used in your script.

The rest of your script can stay as it is.

Joe L.

For completeness: a (collaborative &) customization-free sleep script.

(JoeL´s magic returns the partition on the flash drive where unRAID is installed; "cut -c 1-3" gives us the drive.)

<deleted>

superseded by http://lime-technology.com/forum/index.php?topic=3657.msg41767#msg41767

For completeness: a (collaborative &) customization-free sleep script.

 

(JoeL´s magic returns the partition on the flash drive where unRAID is installed; "cut -c 1-3" gives us the drive.)

[blush]

Of course, you are correct.  You did exactly what was needed, once I got you pointed in the right direction.

[/blush]

Joe L.

After an evening of the family changing their minds about what to watch, and about what unRAID server to watch it from, I give you the sleep-script that suspends the sleep countdown between 5:00pm and 9:59pm.

(It has not been fully tested ...)

<deleted>

superseded by http://lime-technology.com/forum/index.php?topic=3657.msg41767#msg41767

I think I worked out a solution to my problem. Need to do some testing to be sure.

I'm using bwm-ng to check for absence of network traffic before sleeping. Here is code as inserted into ReneV's script.

#Check traffic on eth0 using bwm-ng
traffic=$(bwm-ng -o csv -c 1 -d 0 -T avg | grep eth0 | cut -d";" -f5)
if [ $count -le 0 ] AND [$traffic -eq 0]
then
  # Do pre-sleep activities

If it works it will be a testament to my ability to figure out how to do this scripting on my own with no previous experience. 

If it doesn't work I believe I am at least closing in on the solution.

[Edit]

Whoops. Had to fix the syntax errors first:

if [ $count -le 0 -a $traffic = '0.00' ]

Shows how much I don't know!

Tested the logic. Now to test the script in operation...

[/Edit]

Now, something else to think about.... I have a working setup on which the UNRAID label is on a real internal hard disk, not a flash drive.

Start a new thread for this please. I'm very interested. It's one of my pet peeves with unRAID.