Powerdown package for unRAID v5 and v6 (DEPRECATED)

PeterB · February 6, 2014

Is it safe to assume that powerdown -r is the safest way to reboot?

I always use 'reboot'. With the powerdown package installed, the array is safely stopped before the system goes down. I used this only yesterday, with no ill effect.

sacretagent · February 6, 2014

Guess i am again the only one where it doesn't work

it is weird as it takes the array down

unmounts all disks

but then for some stupid reason i see my plugins all running again without disks mounted

on the gui i see all disks unmounted

but in top i see plex couchand others running...

and of course the computer doesn't shut down

if i do a /sbin/poweroff then he shuts down....

attached syslog sums it up

started /sbin/powerdown at

Feb 5 21:12:28 P8H67 sshd[27109]: Accepted password for root from 192.168.1.9 port 39415 ssh2
Feb 5 21:12:52 P8H67 root: Powerdown initiated

Feb 5 21:12:52 P8H67 rc.unRAID[29106]: Stopping unRAID.

syslog.zip

dlandon · February 6, 2014

Guess i am again the only one where it doesn't work

it is weird as it takes the array down

unmounts all disks

but then for some stupid reason i see my plugins all running again without disks mounted

on the gui i see all disks unmounted

but in top i see plex couchand others running...

and of course the computer doesn't shut down

if i do a /sbin/poweroff then he shuts down....

attached syslog sums it up

started /sbin/powerdown at

Feb 5 21:12:28 P8H67 sshd[27109]: Accepted password for root from 192.168.1.9 port 39415 ssh2
Feb 5 21:12:52 P8H67 root: Powerdown initiated

Feb 5 21:12:52 P8H67 rc.unRAID[29106]: Stopping unRAID.

I don't see in the log where this powerdown package was installed. It looks like you are running the version that Dynamix installs.

This newer version should fix this problem.

sacretagent · February 6, 2014

i installed it from unmenu and yep that is not in the logs... logs rotated at 18.00

but i never realised there was one in dynamix too .... i haven't installed the s3 sleep plugin from dynamix ...

so basically i have 2 installed??

anyway to disable the dynamix one without removing completely having to remove everything?

PeterB · February 6, 2014

Ummm... I'm a little suspicious of this new version of powerdown. Is it pure coincidence that the second powercut since installing 1.05 has resulted in the following entry in my logfile:

Feb  6 15:01:33 Tower rc.unRAID[27297]: Umounting the drives
Feb  6 15:01:33 Tower kernel: nfsd: last server has exited, flushing export cache
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md1 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md2 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: umount: /mnt/disk3: device is busy.
Feb  6 15:01:33 Tower rc.unRAID[27301]:         (In some cases useful info about processes that use
Feb  6 15:01:33 Tower rc.unRAID[27301]:          the device is found by lsof( or fuser(1))
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md4 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md5 umounted
Feb  6 15:01:34 Tower rc.unRAID[27307]: Stopping the Array
Feb  6 15:01:34 Tower kernel: mdcmd (23): stop 
Feb  6 15:01:34 Tower kernel: md: 2 devices still in use.

Of course, on the restart, a parity check started running.

I experience tens of powercuts each week, and this is the first time that I can remember an automatic powercheck being initiated in more than a year.

dlandon · February 6, 2014

Ummm... I'm a little suspicious of this new version of powerdown. Is it pure coincidence that the second powercut since installing 1.05 has resulted in the following entry in my logfile:
Feb  6 15:01:33 Tower rc.unRAID[27297]: Umounting the drives
Feb  6 15:01:33 Tower kernel: nfsd: last server has exited, flushing export cache
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md1 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md2 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: umount: /mnt/disk3: device is busy.
Feb  6 15:01:33 Tower rc.unRAID[27301]:         (In some cases useful info about processes that use
Feb  6 15:01:33 Tower rc.unRAID[27301]:          the device is found by lsof( or fuser(1))
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md4 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md5 umounted
Feb  6 15:01:34 Tower rc.unRAID[27307]: Stopping the Array
Feb  6 15:01:34 Tower kernel: mdcmd (23): stop 
Feb  6 15:01:34 Tower kernel: md: 2 devices still in use.
Of course, on the restart, a parity check started running.

I experience tens of powercuts each week, and this is the first time that I can remember an automatic powercheck being initiated in more than a year.

Can you attach the full log?

PeterB · February 6, 2014

Can you attach the full log?

Sure ...

syslog-20140206-150134.txt.zip

WeeboTech · February 6, 2014

Feb  6 15:01:31 Tower status[27248]: No active PIDS on the array
Feb  6 15:01:31 Tower mountd[5524]: Caught signal 15, un-registering and exiting.
Feb  6 15:01:33 Tower rc.unRAID[27297]: Umounting the drives
Feb  6 15:01:33 Tower kernel: nfsd: last server has exited, flushing export cache
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md1 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md2 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: umount: /mnt/disk3: device is busy.
Feb  6 15:01:33 Tower rc.unRAID[27301]:         (In some cases useful info about processes that use
Feb  6 15:01:33 Tower rc.unRAID[27301]:          the device is found by lsof( or fuser(1))
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md4 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md5 umounted
Feb  6 15:01:34 Tower rc.unRAID[27307]: Stopping the Array
Feb  6 15:01:34 Tower kernel: mdcmd (23): stop 
Feb  6 15:01:34 Tower kernel: md: 2 devices still in use.

There could be some kind of race condition.

When the script checked for active pids, there were none.

Something must have spawned and accessed /mnt/disk3

Perhaps the nfs module was flushing?

What other apps are running in the system?

dlandon · February 6, 2014

Can you attach the full log?

Sure ...

You seem to have multiple versions of the powerdown package installing. Modify your apcupsd plugin lines that install powerdown 1.02 to the following.

<FILE Name="/boot/packages/powerdown-1.05-noarch-unRAID.tgz" Run="CTRLALTDEL=YES upgradepkg --install-new">
<URL>--no-check-certificate https://github.com/dlandon/unraid-snap/raw/master/powerdown-1.05-noarch-unRAID.tgz</URL>
</FILE>

This will install powerdown 1.05. Remove the plugin to install powerdown 1.05 if you installed that. Apcupsd takes care of the powerdown package installation.

sadkisson · February 7, 2014

Well appears to have shutdown cleanly for me. Reviewed log with no errors. Will monitor for awhile. Looks good so far!

PeterB · February 7, 2014

You seem to have multiple versions of the powerdown package installing. Modify your apcupsd plugin lines that install powerdown 1.02 to the following.
<FILE Name="/boot/packages/powerdown-1.05-noarch-unRAID.tgz" Run="CTRLALTDEL=YES upgradepkg --install-new">
<URL>--no-check-certificate https://github.com/dlandon/unraid-snap/raw/master/powerdown-1.05-noarch-unRAID.tgz</URL>
</FILE>
This will install powerdown 1.05. Remove the plugin to install powerdown 1.05 if you installed that. Apcupsd takes care of the powerdown package installation.

Okay, my problem was with a mistyped comment delimiter when modifying apcupsd.plg, resulting in both 1.02 and 1.05 powerdown being installed. However, as far as I can see, this should not have caused a problem - the powerdown plugin should be capable of upgrading cleanly.

I will continue running with just a single install command for powerdown and see what happens.

Looking at the contents of disk3, the one which failed to dismount, the only file/application which could have been active would be minidlna serving a photo to my digital photoframe.

Admittedly, the chance of powerdown being invoked during the time that a photo is actually being served, is fairly small. However, with an average of two powercuts a day, and no change in the minidlna/photoframe configuration (other than adding photos and changing the selection of photos to be displayed) for at least a year, I would have expected the 'window of opportunity' to have been exposed in the past.

dlandon · February 7, 2014

Ummm... I'm a little suspicious of this new version of powerdown. Is it pure coincidence that the second powercut since installing 1.05 has resulted in the following entry in my logfile:
Feb  6 15:01:33 Tower rc.unRAID[27297]: Umounting the drives
Feb  6 15:01:33 Tower kernel: nfsd: last server has exited, flushing export cache
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md1 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md2 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: umount: /mnt/disk3: device is busy.
Feb  6 15:01:33 Tower rc.unRAID[27301]:         (In some cases useful info about processes that use
Feb  6 15:01:33 Tower rc.unRAID[27301]:          the device is found by lsof( or fuser(1))
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md4 umounted
Feb  6 15:01:33 Tower rc.unRAID[27301]: /dev/md5 umounted
Feb  6 15:01:34 Tower rc.unRAID[27307]: Stopping the Array
Feb  6 15:01:34 Tower kernel: mdcmd (23): stop 
Feb  6 15:01:34 Tower kernel: md: 2 devices still in use.
Of course, on the restart, a parity check started running.

I experience tens of powercuts each week, and this is the first time that I can remember an automatic powercheck being initiated in more than a year.

I have implemented a fix for this. This is the classic case of fixing one problem and creating another. The problem I fixed was when powerdown would hang up on shutdown. That has been fixed. An older bug in the script then showed up and created this problem. The new version will fix it. I am still testing because there have been quite a few changes and I want to be sure there are minimum problems.

Going back to version 1.02 for the moment will keep this from happening.

sacretagent · February 8, 2014

Ok i removed the powerdown plugin from unmenu

and installed the PLG you made

and already 2 days he shuts down cleanly

dlandon · February 8, 2014

Version 2.00 of powerdown is available.

Please read the OP for more details.

dlandon · February 8, 2014

I uploaded the wrong version of powerdown to GitHub. I'm working on it now.

betaman · February 8, 2014

Ok, I'm a little confused on exactly what needs to be modified for this version to be auto-installed via unMenu if I'm also using the APCUPSD package? Could someone please post a detailed listing of all the files that need to be modified with the exact modifications so this version auto installs on reboot? Also, for my own edification, is the APCUPSD "package" different than the "plugin" as far as how the powerdown script is installed? I'm assuming the plugin automatically calls the powerdown script whereas the package in UnRAID requires powerdown to also be installed to work properly? Do I have this straight? Finally, is there an easy way to add this package to unMenu so it's listed in the packages directory just like the various versions of APCUPSD are currently? Thanks.

dlandon · February 8, 2014

Ok, I'm a little confused on exactly what needs to be modified for this version to be auto-installed via unMenu if I'm also using the APCUPSD package? Could someone please post a detailed listing of all the files that need to be modified with the exact modifications so this version auto installs on reboot?

unMenu is maintained by Joe L and he will probably update unMenu for the new powerdown package when it is confirmed to be working properly. Because powerdown is still being Beta tested, it's best to not use it until more confidence in its operation is gained.

Also, for my own edification, is the APCUPSD "package" different than the "plugin" as far as how the powerdown script is installed? I'm assuming the plugin automatically calls the powerdown script whereas the package in UnRAID requires powerdown to also be installed to work properly? Do I have this straight?

Yes.

Finally, is there an easy way to add this package to unMenu so it's listed in the packages directory just like the various versions of APCUPSD are currently? Thanks.

Joe L will have to do that.

You should probably wait until unMenu and apcupsd are updated and not try to make any modifications at this point.

betaman · February 8, 2014

Ok, thanks for your response. I'll wait until unMenu is officially updated then.

dlandon · February 8, 2014

The correct 2.00 version is now uploaded to GitHub.

jowi · February 8, 2014

The correct 2.00 version is now uploaded to GitHub.

Do you have a link as well?

dlandon · February 8, 2014

The correct 2.00 version is now uploaded to GitHub.

Do you have a link as well?

Here:

https://github.com/dlandon/unraid-snap/raw/master/powerdown-2.00-noarch-unRAID.tgz

optiman · February 9, 2014

for some reason the old powerdown script worked fine on my rig, but I'll test this new one.

dlandon · February 9, 2014

for some reason the old powerdown script worked fine on my rig, but I'll test this new one.

There was a situation where some plugins were not shutdown properly and the array drives would not be unmounted forcing a parity check on the next start up. Doesn't sound like it affected you.

There is a new feature added for handling shutting down VMs or other special shutdown circumstances.

Thanks for testing it.

jowi · February 9, 2014

Is it possible to print the version of the powerdown script (2.0) to screen when the script runs? I think i installed it but there is no way of telling if 1.02 is called or 2.0?

dlandon · February 9, 2014

Is it possible to print the version of the powerdown script (2.0) to screen when the script runs? I think i installed it but there is no way of telling if 1.02 is called or 2.0?

It should do that. If you happened to get the wrong version 2.00 I first uploaded, you can download it again by deleting the .tgz from the /boot/packages and rebooting.

Powerdown package for unRAID v5 and v6 (DEPRECATED)

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation