I will try the short press when I get home.  I did type powerdown a second time and the syslog says a copy of it is already running.  I also tried to umount my drives.  Two of them indicate that they are busy or in use...but fuser locks up when I run it to see what is in use. 

 

Dan

 

 

I will try the short press when I get home.  I did type powerdown a second time and the syslog says a copy of it is already running.  I also tried to umount my drives.  Two of them indicate that they are busy or in use...but fuser locks up when I run it to see what is in use. 

 

Dan

 

Run powerdown from the console login cli or press the power button and watch the console attached to unRAID to see where the process is hanging up.  There are messages that show the progress as powerdown works.  This can't be done from a telnet session.  It has to be done on the console because all telnet sessions are closed on powerdown and the console is where the progress messages show.

If the "powerdown" command is unable to end a hanging process does it eventually kill power to the server after a given amount of time? I recently used the powerdown command from a ssh session and when I booted unRAID back up it started a parity check.

dlandon,

 

When I head home for lunch, I will run powerdown from the console as you have suggested.  Quick question...I ran powerdown a second time from another telnet session.  In the syslog it shows that second instance and it says that since it was already running that it would exit.  My question is...if I type powerdown at the console will I get the powerdown progress. or will I need to kill the first instance?  If so will the process name be obvious when I run ps -A??

 

Thanks,

Dan

The first initiation of powerdown will show messages on the console no matter how it is initiated - webgui shutdown, power button, or cli.  The second initiation of powerdown is just a warning that it is already running.  Allowing it to run a second time would end up in quite a mess so it is not allowed.

 

EDIT: I suspect that powerdown is trying to perform an operation that is holding up the process and the console messages will give me some information where it is getting stuck.

Perhaps a docker crash. My sabnzbd docker crashes every once in a while and I cannot stop the array or powerdown unless I manually kill the main docker process

So you're saying that Docker is not stopping as it should without manual intervention?  If that's true, you should post a log when it happens so LT can find the cause.  A hangup on shutdown is not a good thing - especially if it is a UPS shutdown and power will eventually be lost.  This affects all shutdowns and reboots with or without the powerdown plugin.  After you manually shutdown the Docker, the last log will be archived to the flash drive and you should post that here so we can see what is happening.

If we are talking about my situation, I stopped all dockers as I want/need to get my basic NAS/unraid stable.  My issue has to be related to all of the instances of smbd processes running (see my other thread http://lime-technology.com/forum/index.php?topic=41861.0).  Using limetech's manual shutdown procedure as quoted from the other thread:

 

I don't get any errors when I run the first two lines of code...my errors start with the third line below.

 

It would be something like this:

 

/etc/rc.d/rc.docker stop
samba stop
umount /mnt/user
umount /mnt/*
sync
mdcmd stop
reboot

 

 

 

Perhaps a docker crash. My sabnzbd docker crashes every once in a while and I cannot stop the array or powerdown unless I manually kill the main docker process

 

I suppose I need to test further to see what is going on. I never seem to have any issues if I type "powerdown -r". I have had a few power outs where the ups sent the powerdown signal but it always comes back up with a parity check. Yesterday I issued just a "powerdown" command and it also came back up with a parity check. I need to test more but I suspect that just the "powerdown" command is doing something strange whereas the "powerdown -r" is working fine. I was thinking my ups battery was bad but maybe not. I'm away from the server for a week so it will have to wait till then unfortunately.

Perhaps a docker crash. My sabnzbd docker crashes every once in a while and I cannot stop the array or powerdown unless I manually kill the main docker process

 

I suppose I need to test further to see what is going on. I never seem to have any issues if I type "powerdown -r". I have had a few power outs where the ups sent the powerdown signal but it always comes back up with a parity check. Yesterday I issued just a "powerdown" command and it also came back up with a parity check. I need to test more but I suspect that just the "powerdown" command is doing something strange whereas the "powerdown -r" is working fine. I was thinking my ups battery was bad but maybe not. I'm away from the server for a week so it will have to wait till then unfortunately.

 

Powerdown and powerdown -r do the same things except that the -r forces a reboot.  Please post one of the logs from a shutdown that causes a parity check.

 

Powerdown will do the best it can to do a clean shutdown, but it forces a shutdown even if it is unclean so the system does not stay powered if there is a UPS shutdown and the power goes off.  Something is not shutting down and powerdown is forcing a shutdown.  A log can tell us what is not shutting down.

Here is my log...as stated in my other post...I did type powerdown a second time (you can see this in the syslog).  The system 8 hours later still had not powered down. 

 

Here is where I am at:  Powercycled Tower...parity check in progress.  Deleted my two dockers and I uninstalled all plugins with the exception of powerdown.  So I am completely stock with the exception of powerdown. 

 

I should be getting additional ram, probably tomorrow.

 

Dan

 

syslog_08_3_2015.txt

 

A log can tell us what is not shutting down.

 

If my assumption is right, that powerdown is force shutting down unRAID and not saving the log. How would you recommend obtaining any pertinent information? Maybe getting the tail end of the syslog?

 

A log can tell us what is not shutting down.

 

If my assumption is right, that powerdown is force shutting down unRAID and not saving the log. How would you recommend obtaining any pertinent information? Maybe getting the tail end of the syslog?

 

It saves the log to /flash/logs each time it shuts down whether clean or unclean.

The powerdown plugin has been modified for compatibility with 6.1-rc3 and is backwards compatible with all v6 versions.

Had a powercut last night, for the first time since installing v6.1 rc3 and powerdown v2.18.  Notifications worked fine, but the shutdown was unclean, resulting in a parity check on restart.  Also, no logs were stored so no means of working out what went wrong.

Had a powercut last night, for the first time since installing v6.1 rc3 and powerdown v2.18.  Notifications worked fine, but the shutdown was unclean, resulting in a parity check on restart.  Also, no logs were stored so no means of working out what went wrong.

Have you actually tested that your system shuts down successfully if you simulate a power cut by shutting of the power to the UPS?  Your symptoms suggest that the unRAID did not successfully complete a shutdown.  This could be because something is preventing unRAID shutting down, or because the UPS  was not able to keep unRAID powered long enough for the shutdown process to complete.

Had a powercut last night, for the first time since installing v6.1 rc3 and powerdown v2.18.  Notifications worked fine, but the shutdown was unclean, resulting in a parity check on restart.  Also, no logs were stored so no means of working out what went wrong.

Have you actually tested that your system shuts down successfully if you simulate a power cut by shutting of the power to the UPS?

It has always shutdown successfully in the past - something that gets tested on an almost daily basis here.  Only significant change since last successful apcupsd-controlled shutdown was the rc3/powerdown v2.18 update.

 

Your symptoms suggest that the unRAID did not successfully complete a shutdown.

Indeed!

 

This could be because something is preventing unRAID shutting down,

That is my belief - something to do with rc3/powerdownv2.18.

 

or because the UPS  was not able to keep unRAID powered long enough for the shutdown process to complete.

 

The UPS can keep my system up for almost an hour, but I have apcupsd configured to shut down after five minutes.

Loss of power on 6.1rc4 and rc5 is not initiating a shutdown of the server.  I've submitted a bug report.

Loss of power on 6.1rc4 and rc5 is not initiating a shutdown of the server.  I've submitted a bug report.

 

Are there any "deprecated" warnings in your syslog ?

 

No.

 

The apcupsd daemon initiates the shutdown.  It's not a web ui function.  I suspect that the recent removal of the scripts from /root has made the apcupsd shutdown on powerfail not work.

The problem is with the apcupsd 'doshutdown' script trying to execute the '/root/powerdown' script that has been removed.

The problem is with the apcupsd 'doshutdown' script trying to execute the '/root/powerdown' script that has been removed.

 

Does that require a change in unraid, a change in the plugin, or something else? Just interested in how it works..

It's part of unRAID.  It's a script in the apcupsd package that LT changed for v6.

The problem is with the apcupsd 'doshutdown' script trying to execute the '/root/powerdown' script that has been removed.

 

Does that require a change in unraid, a change in the plugin, or something else? Just interested in how it works..

What I have done with these last few RC "regressions" is edit the defective OS file, copy it to flash and make an entry in go to copy it from flash to the OS location in case it doesn't get fixed before next boot. When the next RC comes out, I comment it out of go before rebooting and if it's fixed I delete the file from flash and also the entry in go. Sort of a private patch until the real fix comes.

 

The problem is with the apcupsd 'doshutdown' script trying to execute the '/root/powerdown' script that has been removed.

 

Does that require a change in unraid, a change in the plugin, or something else? Just interested in how it works..

What I have done with these last few RC "regressions" is edit the defective OS file, copy it to flash and make an entry in go to copy it from flash to the OS location in case it doesn't get fixed before next boot. When the next RC comes out, I comment it out of go before rebooting and if it's fixed I delete the file from flash and also the entry in go. Sort of a private patch until the real fix comes.

I'm not sure if this is related but it also doesn't seem to be working when hitting the shutdown button. Had to restart as part of the update to 6.1.2 so I just selected restart from the button options. The array stopped but never powered down. I attached the syslog but I'm not sure there's much there.

 

Edit: No attach button?