Powerdown package for unRAID v5 and v6 (DEPRECATED)


dlandon

Recommended Posts

I've been testing powerdown V2.03 on unRAID 6.0-beta3 and it seems to work quite well.  I installed the powerdown plugin from the first post and I do not have apcupsd.  I tested with and without Xen enabled at boot.  I also tested with and without a VM running. 

 

I noticed the custom Kxx scripts are executed in reverse order:  K99 is first and K00 is last.

 

They process in correct order on my test system.

 

Post a syslog.

My custom vm shutdown script is quite simple:

[ -f /var/run/xenstored.pid ] && xl shutdown -a
sleep 20

 

If you only use:

xl shutdown -a

the powerdown will continue while the VMs are shutting down and xen processes could get killed before the VM shutdowns are complete.

 

i intalled powerdown 2.0.3 on my HP40L with unraid 5.0.5. ...

but with powerdown 2.0.3 i can't wake my server with WOL.

 

I did many powerdown cycles on my HP N40L today and WOL worked just fine.

 

Thank you for testing that.  I don't see what the powerdown script has to do with wol.  I think this is a bios feature/setting.

Link to comment
  • Replies 678
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I've been testing powerdown V2.03 on unRAID 6.0-beta3 and it seems to work quite well.  I installed the powerdown plugin from the first post and I do not have apcupsd.  I tested with and without Xen enabled at boot.  I also tested with and without a VM running. 

 

I noticed the custom Kxx scripts are executed in reverse order:  K99 is first and K00 is last.

 

My custom vm shutdown script is quite simple:

[ -f /var/run/xenstored.pid ] && xl shutdown -a
sleep 20

 

If you only use:

xl shutdown -a

the powerdown will continue while the VMs are shutting down and xen processes could get killed before the VM shutdowns are complete.

 

i intalled powerdown 2.0.3 on my HP40L with unraid 5.0.5. ...

but with powerdown 2.0.3 i can't wake my server with WOL.

 

I did many powerdown cycles on my HP N40L today and WOL worked just fine.

 

We can also add -w  (Wait for the domain to complete shutdown before returning)

 

 xl shutdown -a -w

Link to comment

@dlandon: it's definetly the new 2.0.3 powerdown. i dont know why. i double checked WOL in bios and my router.

 

here is the log with powerdown 2.0.3 installed: syslog-20140213-214114.txt.zip

 

after that i deleted the powerdown203.plg and rebooted to be safe. then did a powerdown again and WOL is working! here is the log without powerdown203: syslog-20140213-215338.txt.zip

 

i don't know why it is like this, but the new powerdown kicks the machine pretty heavy in the deeeeptest powerdown ever seen ;)

syslog-20140213-214114.txt.zip

syslog-20140213-215338.txt.zip

Link to comment

@dlandon: it's definetly the new 2.0.3 powerdown. i dont know why. i double checked WOL in bios and my router.

 

here is the log with powerdown 2.0.3 installed: syslog-20140213-214114.txt.zip

 

after that i deleted the powerdown203.plg and rebooted to be safe. then did a powerdown again and WOL is working! here is the log without powerdown203: syslog-20140213-215338.txt.zip

 

i don't know why it is like this, but the new powerdown kicks the machine pretty heavy in the deeeeptest powerdown ever seen ;)

 

The major difference between 1.02 and 2.03 powerdown is that 2.03 goes through the /rc.d/ directory and runs any scripts it finds there with a "stop" command.  I suspect that this file in your /rc.d/ directory may be causing a problem:

 

Feb 13 21:40:46 Stitch rc.unRAID[9255][9450]: Running: "/etc/rc.d/rc.inet1.bak stop"

 

All of your plugins are stopped.  I'm not sure what this means when you wol.

Link to comment

...

C. Wake-On LAN: This has to be enabled in the BIOS (see [1]). The current unRAID releases have a bug in their shutdown scripts causing the network interface to be in the "up" state on powerdown. However, at least on the HP, this prevents WOL to work when the system is powered off (as compared to a WOL from S3/Sleep, which is not supported by the MicroServer BIOS). To fix, this I have added the lines below to my go file:

 

# Fix Wake on LAN
mv /etc/rc.d/rc.inet1 /etc/rc.d/rc.inet1.bak
sed 's/|| \/sbin\/ifconfig/\&\& \/sbin\/ifconfig/' < /etc/rc.d/rc.inet1.bak > /etc/rc.d/rc.inet1
chmod 755 /etc/rc.d/rc.inet1

 

For reference, a copy of my go file can be found here [8]. There's some additional stuff in there that requires extra packages, so please adapt before use.

...

[8] http://www.jens-thiel.de/static/HP/go.txt

 

 

i'm not a programming guy, maybe this can help. thanks in advance :)

Link to comment

...

C. Wake-On LAN: This has to be enabled in the BIOS (see [1]). The current unRAID releases have a bug in their shutdown scripts causing the network interface to be in the "up" state on powerdown. However, at least on the HP, this prevents WOL to work when the system is powered off (as compared to a WOL from S3/Sleep, which is not supported by the MicroServer BIOS). To fix, this I have added the lines below to my go file:

 

# Fix Wake on LAN
mv /etc/rc.d/rc.inet1 /etc/rc.d/rc.inet1.bak
sed 's/|| \/sbin\/ifconfig/\&\& \/sbin\/ifconfig/' < /etc/rc.d/rc.inet1.bak > /etc/rc.d/rc.inet1
chmod 755 /etc/rc.d/rc.inet1

 

For reference, a copy of my go file can be found here [8]. There's some additional stuff in there that requires extra packages, so please adapt before use.

...

[8] http://www.jens-thiel.de/static/HP/go.txt

 

 

i'm not a programming guy, maybe this can help. thanks in advance :)

 

The rc.inet1.bak file will be a problem with powerdown.  Powerdown goes through all the files in the /etc/rc.d/ directory and executes them with a 'stop' parameter.  So both the rc.inet1 and the rc.inet1.bak will be run with the 'stop' parameter.

 

I am adding a feature in the next version where you can specify files in the /etc/rc.d/ directory to skip so you can get around this problem.

Link to comment

is it ready to retry? on github there is still 2.0.3 online. did you commited already? thanks you for the work, will come back with results as soon you allow to download

 

Not quite yet.  I am finishing my testing.  I've made one major change that I want to check out carefully before I commit it.

 

There is one issue with the bare metal unRAID in that it gets stuck and won't come out of run level 6 when shutting down with VMs running.  I have forwarded this to Tom, but I suspect that he is very busy and won't get a fix implemented in the next Beta.

 

This is not something I can fix in the powerdown script.  It is a problem in the unRAID provided rc.local_shutdown script that tries to shutdown xen and fails if VMs are running.  I have a temporary get around, but I am not real comfortable with messing with the unRAID scripts - which is how I get around the issue.  I'd like to see if V6 Beta4 solves this issue.

 

Thanks for testing and providing feedback.

Link to comment

There is a new version of powerdown.  I finally tracked down and fixed the "hang ups" that some were experiencing with.  The system configuration and the particular plugins installed would be troublesome for some and not others.  That's why there have been some that have not experienced any issues and some that have.

 

NOTE: The VMs are shutdown by the unRAID /etc/rc.d/rc.local_shutdown when it shuts down the xendomains.  I have had some issues with this process, but I can't reproduce the issue at the moment.  I've been through so much in the last few weeks working on powerdown, I may have stepped on my own toes and found a non-problem.  I'm not sure this is the ideal way to shut down VMs, but that is how it is handled right now.  I would encourage Tom to install some sort of VM shutdown mechanism when the array is stopped from the webgui.  With VMs running and using shares, the array won't stop until VMs are shutdown.  Right now that is a manual process.  When powerdown is initiated by a power failure, powerdown will do a clean shutdown that should not cause a parity check to start after starting back up.  Those of you with more VM experience than I have might suggest how best to handle shutting down VMs.  Right now I feel it is a bit brute force.

Link to comment

I'm not using Xen, but I'm using ESXi.  Unfortunately ESXi and my UPS don't talk to eachother as it's a cheap APC ups, and doesn't come with a serial cable (my mobo doesn't have a port anyway).  This is what I've done: 

 

- install apcupsd to a raspberry pi

- install apcupsd to all my VMs

- upon power failure shut down unRAID first, then all other VMs

- then shut down ESXi which will shut down any non-responding VMs

- the power off the UPS/Raspberrypi

 

Most mainstream OSes support apcupsd in slave mode, so as long as you leave them enough time to shut down, you can then shut down the host.  Doing that would eliminate the need for the raspberrypi

Link to comment

Johnm in his Atlas thread went into a fairly detailed process on how to get powerdown working on ESXi and an APC UPS with the USB smart cable.  Not sure if you've taken a look at it, but it may be worth your time.  IIRC he made unRAID the ACPUPSD host.

 

http://lime-technology.com/forum/index.php?topic=14695.msg140013#msg140013

 

With unRAID being dom0, unRAID should be the apcupsd master.  That way VMs don't need to concern themselves with the apcupsd slave daemon. Based on what I have seen posted on the forums, the 'xl shutdown -a -w' initiated by dom0 is probably the best way to shut down the VMs cleanly.  I think that unRAID rc.local_shutdown is already doing this as part of the Xen shutdown process.  Whenever I shutdown my server from the command line 'powerdown -r' or 'shutdown -r now' with VMs running, the shutdown of VMs is clean, the array shuts down properly, and the server restarts cleanly.  i.e no parity check when restarted.

 

The one issue I have is with the webgui stop array.  If the VMs are not shutdown first, the array cannot be stopped and it gets in the constant loop of trying to unmount drives.  I think that the webgui stop command should include the VM shutdown.  Possibly a check box to confirm that the user wants the VMs shut down, just like the confirm check box to stop the array.

Link to comment

There is a new version of powerdown.  I finally tracked down and fixed the "hang ups" that some were experiencing with.  ....

Great job you are doing there dlandon!!!

 

Thank you .  Hopefully I am getting rid of the hang ups that drive me and everyone else crazy.

 

p.s. I appreciate the offline code review.  Some good tips and ideas.

Link to comment

I know its easy to comment from the cheap seats, and I'm not running any VM's yet because I'm not ready to take them production yet ... and that is because things like powerdown are only just now getting worked out and I'm waiting on at least beta4 ....

 

so I'll say the next thing, if you haven't testing it yet, is to find a way to forcefully hang a VM to simulate a vm that won't shut down, and confirm that powerdown still works.  Or at the least the array is unmounted with the assumption that is the most important concern above cleanly stopping a VM. 

 

Also any other "edge" cases we might be able to think of.  I'm pretty sure from another thread I read that some OS's don't play with well xl shutdown -a -w and basically ignore it.  I'm not sure what the solution is (apcupsd slave?) or if it is a powerdown.sh solvable problem.  But this would be the time and place to talk about it until it needs to be forked into a vm-OS specific discussion.

 

Thoughts?

 

And of course 100% grat work and thank you dlandon.  No doubt everyone really appreciates it.

Link to comment

Any way to make the github link non version specific so we won't have to edit the apcupsd plug-in link every version?

 

Sent from my Nexus 5 using Tapatalk

 

Personally, I really like have a quick way to check which version of any plug-in that I am running.  It saves a lot of confusion...

 

Plus, we are still in the beta stage and new versions are occurring so fast that it is difficult to keep track of what people have installed at any one time unless the filenames themselves contain that information. 

Link to comment

I know its easy to comment from the cheap seats, and I'm not running any VM's yet because I'm not ready to take them production yet ... and that is because things like powerdown are only just now getting worked out and I'm waiting on at least beta4 ....

 

so I'll say the next thing, if you haven't testing it yet, is to find a way to forcefully hang a VM to simulate a vm that won't shut down, and confirm that powerdown still works.  Or at the least the array is unmounted with the assumption that is the most important concern above cleanly stopping a VM. 

 

Also any other "edge" cases we might be able to think of.  I'm pretty sure from another thread I read that some OS's don't play with well xl shutdown -a -w and basically ignore it.  I'm not sure what the solution is (apcupsd slave?) or if it is a powerdown.sh solvable problem.  But this would be the time and place to talk about it until it needs to be forked into a vm-OS specific discussion.

 

Thoughts?

 

And of course 100% grat work and thank you dlandon.  No doubt everyone really appreciates it.

 

I think I have already had this situation happen where a VM would not shutdown properly.  I'm not sure it's up to powerdown to cover all cases of VMs not behaving as predicted.  There are scripts that get executed by powerdown that will let the user create unique powerdown scripts as needed.

 

I have also discovered some xen configuration file switches that might adjust the behavior of a VM under certain situations.

 

on_poweroff = "destroy"

on_crash = "restart"

on_xend_stop = "shutdown"

 

Maybe tuning these would keep a VM from getting stuck.

 

If a VM needs to know about a power failure, it is easy enough to set up the unRAID apcupsd as master and a VM as slave that will get a shutdown signal when power fails.  Some time ago I did this with a Windows PC as a slave to the unRAID apcupsd and it worked well.

 

I have provided the hooks in powerdown to adjust the power off behavior to unique situations.  This can then be tuned as needed.

Link to comment

Any way to make the github link non version specific so we won't have to edit the apcupsd plug-in link every version?

 

Sent from my Nexus 5 using Tapatalk

 

Right now changes are occurring very quickly and I know it's hard to keep up.  I don't expect this to happen much longer.  I think I may have one more release with some very minor issues addressed - some messages that I cleaned up and any bug fixes from testing.  All planned new features have been implemented.

 

There is a version number on the package.  I.e. powerdown-2.05-noarch-unRAID.tgz and at the command line you can do: '/etc/rc.d/rc.unRAID -v' to see the version.

 

Powerdown is a package that is included in apcupsd, Dynamix, and as a loadable package in unMenu that are version controlled.  Once the dust settles and we are satisfied powerdown is stable, the authors of apcupsd, Dynamix, and unMenu can include powerdown in their plugins and their version control will take care of "what version am I running?".

Link to comment

I presume that powerdown failed to shutdown cleanly because I had a telnet session open?

Feb 24 15:47:35 Tower apcupsd[6761]: Reached run time limit on batteries.
Feb 24 15:47:35 Tower apcupsd[6761]: Initiating system shutdown!
Feb 24 15:47:35 Tower apcupsd[6761]: User logins prohibited
Feb 24 15:47:35 Tower logger: Powerdown initiated
Feb 24 15:47:35 Tower logger: Processing custom scripts
Feb 24 15:47:35 Tower rc.unRAID[3912][3913]: Processing /etc/rc.d/rc.unRAID.d scripts.
Feb 24 15:47:35 Tower logger: Initiating Shutdown with 
Feb 24 15:47:35 Tower shutdown[3919]: shutting down for system halt
Feb 24 15:48:06 Tower init: Switching to runlevel: 0
Feb 24 15:48:08 Tower rc.unRAID[5253][5254]: Powerdown 2.04
Feb 24 15:48:08 Tower rc.unRAID[5253][5255]: Stopping Plugins.
Feb 24 15:48:08 Tower rc.unRAID[5253][5265]: Running: "/etc/rc.d/rc.cache_dirs stop"
Feb 24 15:48:08 Tower cache_dirs: killing cache_dirs process 7462
Feb 24 15:48:08 Tower rc.unRAID[5253][5280]: Running: "/etc/rc.d/rc.couchpotato_v2 stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5515]: Running: "/etc/rc.d/rc.deluge stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5519]: Running: "/etc/rc.d/rc.dnsmasq stop"
Feb 24 15:48:13 Tower dnsmasq[7160]: exiting on receipt of SIGTERM
Feb 24 15:48:13 Tower rc.unRAID[5253][5522]: Running: "/etc/rc.d/rc.dovecot stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5527]: Running: "/etc/rc.d/rc.fan_speed stop"
Feb 24 15:48:13 Tower rc.fan_speed: WARNING: fan_speed called to stop with SERVICE not = disabled
Feb 24 15:48:13 Tower rc.unRAID[5253][5536]: Running: "/etc/rc.d/rc.logitechmediaserver stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5539]: Running: "/etc/rc.d/rc.minidlna stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5542]: Running: "/etc/rc.d/rc.mpop stop"
Feb 24 15:48:13 Tower rc.unRAID[5253][5544]: Running: "/etc/rc.d/rc.mysql stop"
Feb 24 15:48:14 Tower rc.unRAID[5253][5606]: Running: "/etc/rc.d/rc.mysqld stop"
Feb 24 15:48:14 Tower rc.unRAID[5253][5613]: Running: "/etc/rc.d/rc.transmission stop"
Feb 24 15:48:16 Tower rc.unRAID[5253][5647]: Stopping unRAID.
Feb 24 15:48:16 Tower mountd[6474]: Caught signal 15, un-registering and exiting.
Feb 24 15:48:17 Tower rc.unRAID[5253][5666]: Killing active pids on the array drives
Feb 24 15:48:17 Tower kernel: nfsd: last server has exited, flushing export cache
Feb 24 15:48:17 Tower rc.unRAID[5253][5670]: Umounting the drives
Feb 24 15:48:17 Tower rc.unRAID[5253][5674]: /dev/md1 umounted
Feb 24 15:48:17 Tower rc.unRAID[5253][5674]: /dev/md2 umounted
Feb 24 15:48:18 Tower rc.unRAID[5253][5674]: /dev/md4 umounted
Feb 24 15:48:18 Tower rc.unRAID[5253][5674]: /dev/md5 umounted
Feb 24 15:48:18 Tower rc.unRAID[5253][5680]: Synching data
Feb 24 15:48:19 Tower rc.unRAID[5253][5682]: Stopping the Array
Feb 24 15:48:19 Tower kernel: mdcmd (73): stop 
Feb 24 15:48:19 Tower kernel: md: 2 devices still in use.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.