I would love to see an option like the "Default spin down delay", but for shutting down the whole server as "Default shutdown delay". I'm currently using the unRAID for storing my Movie collection, which are played through a fanless topbox in my living room. But as the server makes a lot of noise, I had to put it in the basement. Since I would like to preserve energy while not watching movies, I would love to see a "Default shutdown delay", where the server shuts down after a desired amount of inactivity. To wake it uyp again, I just send a "Wake On Lan magic packet" to the port.

 

The unRAID is great! It would be even more great for me, if this option could be implemented.

 

Sincerely,

caraboli

Hi !

 

I have a script that put my server in sleepmode 10 minutes after all disc have spunn down, and I wake the server automatic when my TviX boots  and I also have a SW on my PC to wake the server.

 

Is this you are looking for ?

 

EDIT

 

To set your server in sleep mode.. look for a script named : s3_notHrHdTcpIp.sh

On my PC I have a SW named : WolCmd, to wake my server.

 

I also have add following scripts

cache_dirs

spinup_when_accessed

unraid_notify (2.53)

 

Sounds interesting!

 

What is "sleep mode"? Does it do a "soft off", "hibernate" or sets the mainboard in low power mode (still turned on). I would like to have the server to "soft off", just like giving turning it down from the unRAID web-page.

Look here -> http://lime-technology.com/wiki/index.php?title=Setup_Sleep_%28S3%29_and_Wake_on_Lan_%28WOL%29

You also found information about s2ram, i need to use that to got a proper wake up on my monitor/keboard.

 

And on this post you find the s3 script -> http://lime-technology.com/forum/index.php?topic=3657.msg41767#msg41767

 

If you like this don't forgot to add bwm-ng -> see this post -> http://lime-technology.com/forum/index.php?topic=3657.msg41705#msg41705

 

My server only use 2watt in sleep mode.

 

More info here -> http://lime-technology.com/forum/index.php?topic=3657.0

 

 

//Peter

Ok

Suspend to RAM! Should work fine. But if there is a power outage during the STR, it will be like an unclean shutdown and the disks needs to get re-synced next time the system starts.

 

I was testing entering a clean "poweroff" instead of "sleep". But it seems like the disks again are in need to get re-synced during next reboot.

 

Is there any command that will execute the "Stop" -button command in the unRAID web-gui? If so, the array could be stopped end then powered down with "poweroff".

I have this one to care of the power outage -> http://lime-technology.com/forum/index.php?topic=1528.msg42878#msg42878   

UPS!

Sure... But what happens when it runs out of battery during a longer outage? 

It shut down the server before that, it used the clean shutdown script that you can find here: http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#Power_Down   

 

UPS!

Sure... But what happens when it runs out of battery during a longer outage? 

apcupsd is smart enough to initiate a shutdown-sequence when its batteries are still able.  Mine is set to start a shutdown when 4 minutes run time remain.  The APC brand UPS connects via a USB cable to the unRAID server.

 

You'll need to install the powerdown package developed by WeboTech.  It is used by apcupsd to cleanly "Stop" the array and shut down.

 

http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#Power_Down

 

Easiest way to install both the powerdown script and the apcupsd UPS monitoring progran is to use the package-manager built into the unMENU add-on

(install unMENU, it can be used to download, install and re-install on re-boot the others)

 

unMENU is described here: http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#UnMENU

 

Joe L.

 

 

Thanks Joe!

 

The shutdown script looks useful. I'm about to test the unMenu as well. Have downloaded the 3 zip files with "wget" and placed them in a new folder "/boot/unmenu". But how do I unpack the zip-files? It doesn't seem to be a zip or unzip application in the unRAID distribution.

Thanks Joe!

 

The shutdown script looks useful. I'm about to test the unMenu as well. Have downloaded the 3 zip files with "wget" and placed them in a new folder "/boot/unmenu". But how do I unpack the zip-files? It doesn't seem to be a zip or unzip application in the unRAID distribution.

unzip them in windows... then put the resulting files on the flash drive.  Its top level folder is at \\tower\flash when viewed from window's file explorer.

So, browse to \\tower\flash\unmenu using file-explorer (not the web-browser) and you should be able to unzip them in place.

 

Joe L.

Oki! Worked fine!!

The UnMenu is just beautiful!

 

But starting the "uu", outputs the following error message (but it still works):

 

root@Tower:/boot/unmenu# ./uu
root@Tower:/boot/unmenu# unmenu[1357]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory

Hi ! 

 

You have the information on this page -> http://lime-technology.com/wiki/index.php?title=Third_Party_Boot_Flash_Plugin_Architecture

 

You need to create a file structure at your flash.

 

//Peter

 

Oki! Worked fine!!

The UnMenu is just beautiful!

 

But starting the "uu", outputs the following error message (but it still works):

 

root@Tower:/boot/unmenu# ./uu
root@Tower:/boot/unmenu# unmenu[1357]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory

 

Check out the Third Party Boot Flash Plugin Architecture of theiunRAID wiki.  Unmenu takes advantage of the Third Party Boot Flash Plugin Architecture if it exists.

I was first    , just kidding 

 Unmenu takes advantage of the Third Party Boot Flash Plugin Architecture if it exists.

Not exactly true.

 

First, the third party architecture has NEVER been implemented by anyone in its entirety.  We do not have any "events" that can trigger scripts at the various pre/post events.

 

Second, the architecture was proposed as all the possible desirable events.  I will be very happy if we have 2 events in the 5.0 version of unRAID,

one event that can invoke tasks

AFTER THE ARRAY IS ON-LINE

  This will allow you to start up add-on processes.

 

BEFORE THE ARRAY IS STOPPED

  This will allow you to cleanly stop any add-on processes.

 

The actual directory structure to be used will be decided by Tom as he codes the 5.0 version of unRAID.  He may elect to keep it simple and simply have a single rc.d directory, exactly similar to the current method used by slackware in /etc/rc.d

(That is actually my preference, but the structure will be up to lime-technology)  simpler is easier on everybody, especially since all the actions for a given add-on would be in a single script, rather than in multiple scripts in multiple directories. (I think that could get messy to manage over time as scripts evolve)

 

Now, as far as unMENU

If /boot/custom/etc/rc.d exists, and you request that ANY package is re-installed on re-boot, unMENU will add a task in that folder to be invoked in turn.  The actual invoking of those tasks is assumed to already be in place.  If it is not, then the one task unMENU adds will not be invoked, and the re-install (the package.auto_install scripts) will not occur.

 

If /boot/custom/etc/rc.d does not exist, then a line is appended to the "go" script when you first request a package get re-installed on re-boot.

 

So, to repeat.. the THIRD PARTY BOOT ARCHITECTURE does not exist as far as I know on anyone's server...  A small portion of it has been implemented, but only to start add-ons, and not to stop them, and everyone will need changes once unRAID 5.0beta1 is released.

 

Joe L.

 

 

 Unmenu takes advantage of the Third Party Boot Flash Plugin Architecture if it exists.

Not exactly true.

 

First, the third party architecture has NEVER been implemented by anyone in its entirety.   We do not have any "events" that can trigger scripts at the various pre/post events.

 

Second, the architecture was proposed as all the possible desirable events.   I will be very happy if we have 2 events in the 5.0 version of unRAID,

one event that can invoke tasks

AFTER THE ARRAY IS ON-LINE

   This will allow you to start up add-on processes.

 

BEFORE THE ARRAY IS STOPPED

   This will allow you to cleanly stop any add-on processes.

 

The actual directory structure to be used will be decided by Tom as he codes the 5.0 version of unRAID.  He may elect to keep it simple and simply have a single rc.d directory, exactly similar to the current method used by slackware in /etc/rc.d

(That is actually my preference, but the structure will be up to lime-technology)  simpler is easier on everybody, especially since all the actions for a given add-on would be in a single script, rather than in multiple scripts in multiple directories. (I think that could get messy to manage over time as scripts evolve)

 

Now, as far as unMENU

If /boot/custom/etc/rc.d exists, and you request that ANY package is re-installed on re-boot, unMENU will add a task in that folder to be invoked in turn.  The actual invoking of those tasks is assumed to already be in place.   If it is not, then the one task unMENU adds will not be invoked, and the re-install (the package.auto_install scripts) will not occur.

 

If /boot/custom/etc/rc.d does not exist, then a line is appended to the "go" script when you first request a package get re-installed on re-boot.

 

So, to repeat.. the THIRD PARTY BOOT ARCHITECTURE does not exist as far as I know on anyone's server...  A small portion of it has been implemented, but only to start add-ons, and not to stop them, and everyone will need changes once unRAID 5.0beta1 is released.

 

Joe L.

 

 

 

Thanks you for clearing that up.  I did realize that it worked that way, but I guess I assumed others would understand that... which is my mistake.  If I get a chance I will update thesThird Party Boot Flash Plugin Architecture page to include some extra info on how to implement it if so desired.

Thank you all, anyway! 

 

Works fine now after creating the file structure!

Thank you all, anyway! 

 

Works fine now after creating the file structure!

Probably because the line to re-install packages was already appended to your "config/go" script.    About all that you did is silence the error message when unmenu went to test if the /boot/custom/etc/rc.d directory exists.  (I'll see if I can suppress that error in future versions of unMENU.)