Powerdown package for unRAID v5 and v6 (DEPRECATED)

Sorry I got confused.  Yesterday the server started with a parity check, so you'll be needing the last log file before then...

Cheers.

syslog-20150307-124346.txt

Sorry I got confused.  Yesterday the server started with a parity check, so you'll be needing the last log file before then...

Cheers.

 

Mar  7 12:43:46 Tower2 rc.unRAID[23087][23225]: umount2: Device or resource busy
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23225]: umount: /mnt/disk1: device is busy.
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23225]:         (In some cases useful info about processes that use
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23225]:          the device is found by lsof( or fuser(1))
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23225]: umount2: Device or resource busy
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23227]: Active pids left on the array drives
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23230]:                      USER        PID ACCESS COMMAND
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23230]: /dev/md1:            root     kernel mount /mnt/disk1
Mar  7 12:43:46 Tower2 rc.unRAID[23087][23230]:                      root      12436 ..c.. bash

 

Looks like a bash script was running on /mnt/disk1?

No idea what that would have been...  I have to telnet in in order to run powerdown.  No other ideas, must have just been an anomaly I guess.

 

Thanks.

No idea what that would have been...  I have to telnet in in order to run powerdown.

You probably forgot to cd back to / before you ran powerdown. If you had your telnet session pwd anywhere in the /mnt/* structure it will hang up the array waiting for the session to let loose of the mounted disk.

 

The official approved method of shutting down the array is from the web GUI.

No idea what that would have been...  I have to telnet in in order to run powerdown.

You probably forgot to cd back to / before you ran powerdown. If you had your telnet session pwd anywhere in the /mnt/* structure it will hang up the array waiting for the session to let loose of the mounted disk.

 

The powerdown plugin/script deals with this situation.  I'm guessing that, for some reason, the script was not invoked.

 

The official approved method of shutting down the array is from the web GUI.

 

... and the 'stop array' will hang at 'unmounting...' until any current terminal sessions 'cd' away from array devices.

I'm using V6beta15 I installed the Powerdown package v6 on the plugin tab all went fine.  The question I have now is can I put a line in my Go file

ie: "powerdown | at 02:00" ?

 

this works on my Version 5 system with unmenu

 

just testing v6b15 to see if I want to jump to it now.

I'm using V6beta15 I installed the Powerdown package v6 on the plugin tab all went fine.  The question I have now is can I put a line in my Go file

ie: "powerdown | at 02:00" ?

 

this works on my Version 5 system with unmenu

 

just testing v6b15 to see if I want to jump to it now.

 

The "at" command executes only once, but I suppose you want to have this repetitive, as every day at the same time.

 

With V6 there is support to create your own "cron" file which gets loaded upon system start.

 

Create the file  powerdown.cron under the folder /boot/config/plugins/powerdown and put in there the following content (example)

 

# Daily automated powerdown at fixed time:

0 2 * * * /usr/local/sbin/powerdown &> /dev/null

The above will start powerdown every morning at 02:00 am. Adjust the time to your requirements.

 

 

 

Shouldn't a one time powerdown be sufficient? Then on next boot, the at is done again. So cron shouldn't be necessary.

Shouldn't a one time powerdown be sufficient? Then on next boot, the at is done again. So cron shouldn't be necessary.

 

In principle yes, if the system is always shutdown and restarted.

 

In case the 'at' command is cancelled or not executed then there is no more automatic shutdown, but this can be by choice of course.

 

I wanted to highlight that in v6 a new method exists to add cron entries (the notifications system makes use of that), and it opens up new ways of doing things.

 

With V6 there is support to create your own "cron" file which gets loaded upon system start.

 

Create the file  powerdown.cron under the folder /boot/config/plugins/powerdown and put in there the following content (example)

 

# Daily automated powerdown at fixed time:

0 2 * * * /usr/local/sbin/powerdown &> /dev/null

The above will start powerdown every morning at 02:00 am. Adjust the time to your requirements.

...I wanted to highlight that in v6 a new method exists to add cron entries (the notifications system makes use of that), and it opens up new ways of doing things.

I totally skipped over that part. Very nice. Thanks

Can someone tell me when exactly the S00.sh script gets executed? Is it immediately after the go script is finished and all services like smb and nfsd are up and running?

 

Also is there a way to check if a certain file, like /proc/fs/nfsd/max_block_size is available, after which certain commands are executed?

 

And can I add a delay to the script?

The latest betas of V6 come with apcupsd, does this also include powerdown? Can I install the latest powerdown package without any problem?

Can someone tell me when exactly the S00.sh script gets executed? Is it immediately after the go script is finished and all services like smb and nfsd are up and running?

 

On the array started event.  I don't know for sure about the services, but I think they are started after the array has started.

 

Also is there a way to check if a certain file, like /proc/fs/nfsd/max_block_size is available, after which certain commands are executed?

 

if [ -f /proc/fs/nfsd/max_block_size ]
then
# do stuff
fi

 

And can I add a delay to the script?

 

Yes, but other array starting events will be delayed.

The latest betas of V6 come with apcupsd, does this also include powerdown? Can I install the latest powerdown package without any problem?

 

Powerdown is a separate plugin and is not part of apcupsd.  It can be installed without a problem.

Thanks dlandon. What exactly are other array starting events ?

Should fi in the above lines, just below #do stuff, read if?

Should fi in the above lines, just below #do stuff, read if?

No. fi marks the end of the if block.

Thanks all. The few lines with my lines added work and are properly executed after booting. Great addition to powerdown!

 

 

When I try to power down with:

echo "/sbin/powerdown" | at 01:00

the next restart will always invoke a parity check.

 

Attached is my syslog from yesterday/this morning. I'm very grateful for your feedback.

syslog-20150514-010248.txt

When I try to power down with:

echo "/sbin/powerdown" | at 01:00

the next restart will always invoke a parity check.

 

Attached is my syslog from yesterday/this morning. I'm very grateful for your feedback.

 

Something is keeping disk1 busy.

 

Are you running any Dockers?

Thanks a lot for looking into this. I'm running (dockers) PlexMediaServer, PlexReport, PlexWatch and SABnzbd.

Thanks a lot for looking into this. I'm running (dockers) PlexMediaServer, PlexReport, PlexWatch and SABnzbd.

 

I would guess that one of the Dockers is keeping disk1 busy.  I don't know how those Dockers work, so I can't suggest any fixes for you.

The powerdown package appears to make a last ditch effort to kill PIDs that are using the array drives, but I don't think it is working quite as intended.

 

From rc.unRAID version 2.13:

logger "Killing active pids on the array drives"
/usr/bin/fuser -k /mnt/user/* /mnt/disk* /mnt/cache /dev/md* 2>&1 | logger

 

This will kill processes that are using the high level directories but it won't kill processes using subdirectories or files.

 

As an example, when I have a shell open using the /mnt/disk7/ directory and another shell open using the /mnt/disk7/video/ directory, I get these results:

root@tower:~# fuser -v /mnt/disk7
                     USER        PID ACCESS COMMAND
/mnt/disk7:          root     kernel mount /mnt/disk7
                     root      14286 ..c.. bash
root@tower:~# fuser -vm /mnt/disk7
                     USER        PID ACCESS COMMAND
/mnt/disk7:          root     kernel mount /mnt/disk7
                     root      14286 ..c.. bash
                     root      32333 ..c.. bash
root@tower:~# fuser -k /mnt/disk7
/mnt/disk7:          14286c
root@tower:~# fuser -mk /mnt/disk7
/mnt/disk7:          32333c

 

The shell using /mnt/disk7/video/ is not killed until the -m option is added to the fuser -k command. Perhaps the -m option should be added in rc.unRAID to make the last ditch effort more effective. I would also add the -v option to get more information into the log about PIDs that had to be killed:

logger "Killing active pids on the array drives"
/usr/bin/fuser -mvk /mnt/user/* /mnt/disk* /mnt/cache /dev/md* 2>&1 | logger

 

The shell using /mnt/disk7/video/ is not killed until the -m option is added to the fuser -k command. Perhaps the -m option should be added in rc.unRAID to make the last ditch effort more effective. I would also add the -v option to get more information into the log about PIDs that had to be killed:

logger "Killing active pids on the array drives"
/usr/bin/fuser -mvk /mnt/user/* /mnt/disk* /mnt/cache /dev/md* 2>&1 | logger

 

Done.  2.14 available.

Done.  2.14 available.

Thanks to both you and Freddie!  Very fast work!