March 10, 201511 yr 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
March 10, 201511 yr Author 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?
March 10, 201511 yr 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.
March 11, 201511 yr 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.
March 11, 201511 yr 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.
May 9, 201511 yr 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.
May 9, 201511 yr 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.
May 9, 201511 yr Shouldn't a one time powerdown be sufficient? Then on next boot, the at is done again. So cron shouldn't be necessary.
May 9, 201511 yr 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.
May 9, 201511 yr 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
May 10, 201511 yr 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?
May 10, 201511 yr The latest betas of V6 come with apcupsd, does this also include powerdown? Can I install the latest powerdown package without any problem?
May 10, 201511 yr Author 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.
May 10, 201511 yr Author 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.
May 10, 201511 yr Should fi in the above lines, just below #do stuff, read if? No. fi marks the end of the if block.
May 10, 201511 yr Thanks all. The few lines with my lines added work and are properly executed after booting. Great addition to powerdown!
May 14, 201511 yr 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
May 14, 201511 yr Author 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?
May 14, 201511 yr Thanks a lot for looking into this. I'm running (dockers) PlexMediaServer, PlexReport, PlexWatch and SABnzbd.
May 14, 201511 yr Author 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.
May 14, 201511 yr 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
May 16, 201511 yr Author 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.
Archived
This topic is now archived and is closed to further replies.