February 24, 201412 yr Author 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. unRAID 5 or 6? Can you post the complete log?
February 24, 201412 yr unRAID 5 or 6? Can you post the complete log? unRAID v5.0.5. Full syslog attached. syslog-20140224-154819.txt.zip
February 24, 201412 yr Author unRAID 5 or 6? Can you post the complete log? unRAID v5.0.5. Full syslog attached. It appears that /dev/md3 and /dev/md6 did not unmount because some NFS files were still open on them. Transmission downloading at that time? There is an issue in 2.04 in that the file sync is done after the drives are unmounted. This should be done before the unmounts. This has been changed in 2.05. I have also added some additional parameters to the umount command that should help with NFS file system.
February 25, 201412 yr unRAID 5 or 6? Can you post the complete log? unRAID v5.0.5. Full syslog attached. It appears that /dev/md3 and /dev/md6 did not unmount because some NFS files were still open on them. Interesting ... I didn't think I have an md6. As far as I can see from the log, all mounts associated with disk3 had been unmounted well before the powerdown. Can you explain why you believe there is still an nfs mount open on md3? I had been out for five hours when the power outage occurred and my main desktop machine was in suspend state. I don't believe that any other users would have been using nfs. Transmission downloading at that time? Transmission runs as a plugin - it shouldn't be using nfs mounts. Apart from which, Transmission downloads its torrents to disk1. There is an issue in 2.04 in that the file sync is done after the drives are unmounted. This should be done before the unmounts. This has been changed in 2.05. I have also added some additional parameters to the umount command that should help with NFS file system. Ah, that would be better.
February 25, 201412 yr Author unRAID 5 or 6? Can you post the complete log? unRAID v5.0.5. Full syslog attached. It appears that /dev/md3 and /dev/md6 did not unmount because some NFS files were still open on them. Interesting ... I didn't think I have an md6. As far as I can see from the log, all mounts associated with disk3 had been unmounted well before the powerdown. Can you explain why you believe there is still an nfs mount open on md3? I had been out for five hours when the power outage occurred and my main desktop machine was in suspend state. I don't believe that any other users would have been using nfs. Transmission downloading at that time? Transmission runs as a plugin - it shouldn't be using nfs mounts. Apart from which, Transmission downloads its torrents to disk1. There is an issue in 2.04 in that the file sync is done after the drives are unmounted. This should be done before the unmounts. This has been changed in 2.05. I have also added some additional parameters to the umount command that should help with NFS file system. Ah, that would be better. md3 did not unmount. I assumed a md6 but it all seems to be on md3 - 2 devices. I added a switch to the umount to force an un mount that wasn't there before. Something was blocking the un mount of md3 and it didn't un mount. The sync command is supposed to commit any disk data in memory to the physical disk, but I don't know if it would hold up an umount. I'll release 2.05 soon and you can give that a try.
February 25, 201412 yr unRAID 5 or 6? Can you post the complete log? unRAID v5.0.5. Full syslog attached. It appears that /dev/md3 and /dev/md6 did not unmount because some NFS files were still open on them. Interesting ... I didn't think I have an md6. As far as I can see from the log, all mounts associated with disk3 had been unmounted well before the powerdown. Can you explain why you believe there is still an nfs mount open on md3? I had been out for five hours when the power outage occurred and my main desktop machine was in suspend state. I don't believe that any other users would have been using nfs. Transmission downloading at that time? Transmission runs as a plugin - it shouldn't be using nfs mounts. Apart from which, Transmission downloads its torrents to disk1. There is an issue in 2.04 in that the file sync is done after the drives are unmounted. This should be done before the unmounts. This has been changed in 2.05. I have also added some additional parameters to the umount command that should help with NFS file system. Ah, that would be better. md3 did not unmount. Yes, I can see that. I assumed a md6 but it all seems to be on md3 - 2 devices. I can only see one device accessing md3 (/mnt/disk3, /mnt/user/Downloaded, /mnt/user/Karaoke, /mnt/user/Photos) - that is 10.2.1.15, my desktop machine running Ububtu, which had been in suspend state for five hours before the power failure. For each of those mount points, the last entry logged by mountd is an unmount request. So, I'm still puzzled as to where an open nfs mount might have come from. Also, as I've stated earlier, it is months since I had an unsafe shutdown while using powerdown 1.02 (my slightly modified version). At times the system has been showing more than 60 days since last parity check. I think that this is quite remarkable, given the number of power outages experienced here. The last time I remember a forced parity check was after three 10 minute powercuts in the space of an hour - there simply wasn't enough reserve in the UPS battery to hold the power long enough for a clean powerdown. Contrast that with my experience since installing powerdown 2.x - two (or is it three?) unclean shutdowns in a relatively short period. I don't think my usage or habits have changed significantly - the only obvious change is powerdown 1.02 -> 2.x Perhaps the forced unmount and repositioning the sync will resolve the issue. The only plugin which should be accessing any of those mounts is minidlna ... ah, I have updated the minidlna binary recently - I wonder whether that has introduced a problem? With the abbreviated logging from powerdown, we cannot tell whether all the plugin processes have exited. I added a switch to the umount to force an un mount that wasn't there before. Something was blocking the un mount of md3 and it didn't un mount. The sync command is supposed to commit any disk data in memory to the physical disk, but I don't know if it would hold up an umount. I'll release 2.05 soon and you can give that a try. Great, I look forward to that.
February 25, 201412 yr We've just returned from a short power outage. Yet again, parity check is running - log looks exactly the same - md3 not showing as unmounted and kernel reporting 2 devices still in use.
February 25, 201412 yr Author We've just returned from a short power outage. Yet again, parity check is running - log looks exactly the same - md3 not showing as unmounted and kernel reporting 2 devices still in use. You have a lot of plugins installed and any one of them could be holding open a file or directory. If you do a normal stop from the webgui does the array stop? If not what action do you have to perform to get it to stop?
February 25, 201412 yr We've just returned from a short power outage. Yet again, parity check is running - log looks exactly the same - md3 not showing as unmounted and kernel reporting 2 devices still in use. You have a lot of plugins installed and any one of them could be holding open a file or directory. Yes, I do have several plugins running. The only one which should be accessing disk3 is minidlna (only requiring read access, but I should check how the files are actually opened) which, as I said earlier, I recently updated from 1.0.25 to 1.1.0. I'm presuming that the '2 devices in use' could be /mnt/user/Photos and /mnt/disk3 (which is where the Photos directory resides). If you do a normal stop from the webgui does the array stop? If not what action do you have to perform to get it to stop? Yes, it does stop, but sometimes it takes several attempts to unmount all the drives. During a power outage, my digital photo frame (which is the only dlna client) will have powered off abruptly five minutes before powerdown kicks in. I think that I will wait and see how well powerdown 2.05 performs. If the problem persists, I will then try downgrading minidlna back to 1.0.25.
February 25, 201412 yr When you start testing I'd be sure to do a "real" test and pull the plug on that picture frame a 5 minutes before you pull the plug on the server
February 25, 201412 yr Author We've just returned from a short power outage. Yet again, parity check is running - log looks exactly the same - md3 not showing as unmounted and kernel reporting 2 devices still in use. You have a lot of plugins installed and any one of them could be holding open a file or directory. Yes, I do have several plugins running. The only one which should be accessing disk3 is minidlna (only requiring read access, but I should check how the files are actually opened) which, as I said earlier, I recently updated from 1.0.25 to 1.1.0. I'm presuming that the '2 devices in use' could be /mnt/user/Photos and /mnt/disk3 (which is where the Photos directory resides). If you do a normal stop from the webgui does the array stop? If not what action do you have to perform to get it to stop? Yes, it does stop, but sometimes it takes several attempts to unmount all the drives. During a power outage, my digital photo frame (which is the only dlna client) will have powered off abruptly five minutes before powerdown kicks in. I think that I will wait and see how well powerdown 2.05 performs. If the problem persists, I will then try downgrading minidlna back to 1.0.25. I found a typo in the logic that kills the active processes on the devices which was probably preventing clean unmounts that I've fixed. I moved the sync to the proper place in the powerdown sequence. Please install version 2.05 of powerdown. It is uploaded to the GitHub repository. Once it is installed, go to the main console and type "powerdown -r" to simulate a power failure and shut down the system the same way, except it will reboot in this case. Send me the log once you've done that so I can look at it. I've added some additional information to the log to help me track down this issue if it is still occurring. By doing the test this way, we don't have to wait until a power outage and cause a writing parity check while you are not there.
February 27, 201412 yr I found a typo in the logic that kills the active processes on the devices which was probably preventing clean unmounts that I've fixed. I moved the sync to the proper place in the powerdown sequence. Please install version 2.05 of powerdown. It is uploaded to the GitHub repository. Okay, yesterday we had a power outage before I had time to install 2.05. It's now just before midday on Thursday and power has just returned after the third outage of the day. On the first and third occurrences, the system shut down cleanly: Feb 27 11:19:49 Tower apcupsd[6801]: Reached run time limit on batteries. Feb 27 11:19:49 Tower apcupsd[6801]: Initiating system shutdown! Feb 27 11:19:49 Tower apcupsd[6801]: User logins prohibited Feb 27 11:19:49 Tower logger: Powerdown initiated Feb 27 11:19:49 Tower logger: Powerdown V2.05 Feb 27 11:19:49 Tower logger: Processing custom scripts Feb 27 11:19:49 Tower rc.unRAID[20097][20098]: Processing /etc/rc.d/rc.unRAID.d scripts. Feb 27 11:19:49 Tower logger: Initiating Shutdown with Feb 27 11:19:49 Tower shutdown[20104]: shutting down for system halt Feb 27 11:19:51 Tower init: Switching to runlevel: 0 Feb 27 11:19:53 Tower rc.unRAID[20195][20196]: Powerdown V2.05 Feb 27 11:19:53 Tower rc.unRAID[20195][20197]: Stopping Plugins. Feb 27 11:19:53 Tower rc.unRAID[20195][20205]: Running: "/etc/rc.d/rc.cache_dirs stop" Feb 27 11:19:53 Tower cache_dirs: killing cache_dirs process 7591 Feb 27 11:19:53 Tower rc.unRAID[20195][20217]: Running: "/etc/rc.d/rc.couchpotato_v2 stop" Feb 27 11:19:58 Tower rc.unRAID[20195][20268]: Running: "/etc/rc.d/rc.dnsmasq stop" Feb 27 11:19:58 Tower dnsmasq[7201]: exiting on receipt of SIGTERM Feb 27 11:19:58 Tower rc.unRAID[20195][20271]: Running: "/etc/rc.d/rc.dovecot stop" Feb 27 11:19:58 Tower rc.unRAID[20195][20276]: Running: "/etc/rc.d/rc.fan_speed stop" Feb 27 11:19:58 Tower rc.fan_speed: WARNING: fan_speed called to stop with SERVICE not = disabled Feb 27 11:19:58 Tower rc.unRAID[20195][20285]: Running: "/etc/rc.d/rc.logitechmediaserver stop" Feb 27 11:19:58 Tower rc.unRAID[20195][20288]: Running: "/etc/rc.d/rc.minidlna stop" Feb 27 11:19:58 Tower rc.unRAID[20195][20291]: Running: "/etc/rc.d/rc.mpop stop" Feb 27 11:19:58 Tower rc.unRAID[20195][20293]: Running: "/etc/rc.d/rc.mysql stop" Feb 27 11:20:00 Tower rc.unRAID[20195][20339]: Running: "/etc/rc.d/rc.mysqld stop" Feb 27 11:20:00 Tower rc.unRAID[20195][20346]: Running: "/etc/rc.d/rc.transmission stop" Feb 27 11:20:02 Tower rc.unRAID[20195][20364]: Stopping unRAID. Feb 27 11:20:02 Tower mountd[6515]: Caught signal 15, un-registering and exiting. Feb 27 11:20:03 Tower rc.unRAID[20195][20387]: Killing active pids on the array drives Feb 27 11:20:03 Tower kernel: nfsd: last server has exited, flushing export cache Feb 27 11:20:03 Tower rc.unRAID[20195][20391]: Synching data Feb 27 11:20:06 Tower rc.unRAID[20195][20393]: Umounting the drives Feb 27 11:20:08 Tower rc.unRAID[20195][20397]: /dev/md1 umounted Feb 27 11:20:10 Tower rc.unRAID[20195][20397]: /dev/md2 umounted Feb 27 11:20:11 Tower rc.unRAID[20195][20397]: /dev/md3 umounted Feb 27 11:20:13 Tower rc.unRAID[20195][20397]: /dev/md4 umounted Feb 27 11:20:15 Tower rc.unRAID[20195][20397]: /dev/md5 umounted Feb 27 11:20:15 Tower rc.unRAID[20195][20402]: Stopping the Array Feb 27 11:20:15 Tower kernel: mdcmd (24): stop Feb 27 11:20:15 Tower kernel: md: md_do_sync: got signal, exit... Feb 27 11:20:15 Tower kernel: md: recovery thread sync completion status: -4 Feb 27 11:20:15 Tower kernel: md1: stopping Feb 27 11:20:15 Tower kernel: md2: stopping Feb 27 11:20:15 Tower kernel: md3: stopping Feb 27 11:20:15 Tower kernel: md4: stopping Feb 27 11:20:15 Tower kernel: md5: stopping Feb 27 11:20:21 Tower mdstatusdiff[20419]: --- /tmp/mdcmd.20195.1^I2014-02-27 11:20:15.071650963 +0800 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +++ /tmp/mdcmd.20195.2^I2014-02-27 11:20:21.451642895 +0800 Feb 27 11:20:21 Tower mdstatusdiff[20419]: @@ -1,14 +1,14 @@ Feb 27 11:20:21 Tower mdstatusdiff[20419]: sbName=/boot/config/super.dat Feb 27 11:20:21 Tower mdstatusdiff[20419]: sbVersion=2.1.0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: sbCreated=1298993082 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -sbUpdated=1393468420 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -sbEvents=1764 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -sbState=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +sbUpdated=1393471215 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +sbEvents=1766 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +sbState=1 Feb 27 11:20:21 Tower mdstatusdiff[20419]: sbNumDisks=6 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -sbSynced=1393377864 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +sbSynced=1393471215 Feb 27 11:20:21 Tower mdstatusdiff[20419]: sbSyncErrs=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdVersion=2.2.0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -mdState=STARTED Feb 27 11:20:21 Tower mdstatusdiff[20419]: +mdState=STOPPED Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdNumProtected=6 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdNumDisabled=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdDisabledDisk=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: @@ -17,11 +17,11 @@ Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdNumMissing=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdMissingDisk=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdNumNew=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -mdResync=2930266532 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +mdResync=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: mdResyncCorr=1 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -mdResyncPos=247813308 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -mdResyncDt=32 Feb 27 11:20:21 Tower mdstatusdiff[20419]: -mdResyncDb=2910528 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +mdResyncPos=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +mdResyncDt=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: +mdResyncDb=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: diskNumber.0=0 Feb 27 11:20:21 Tower mdstatusdiff[20419]: diskName.0= Feb 27 11:20:21 Tower mdstatusdiff[20419]: diskSize.0=2930266532 On the second occurrence, md3 failed to dismount, as before: Feb 27 08:08:02 Tower apcupsd[6775]: Reached run time limit on batteries. Feb 27 08:08:02 Tower apcupsd[6775]: Initiating system shutdown! Feb 27 08:08:02 Tower apcupsd[6775]: User logins prohibited Feb 27 08:08:02 Tower logger: Powerdown initiated Feb 27 08:08:02 Tower logger: Powerdown V2.05 Feb 27 08:08:02 Tower logger: Processing custom scripts Feb 27 08:08:02 Tower rc.unRAID[31233][31234]: Processing /etc/rc.d/rc.unRAID.d scripts. Feb 27 08:08:02 Tower logger: Initiating Shutdown with Feb 27 08:08:02 Tower shutdown[31240]: shutting down for system halt Feb 27 08:08:25 Tower init: Switching to runlevel: 0 Feb 27 08:08:27 Tower rc.unRAID[31879][31880]: Powerdown V2.05 Feb 27 08:08:27 Tower rc.unRAID[31879][31881]: Stopping Plugins. Feb 27 08:08:27 Tower rc.unRAID[31879][31889]: Running: "/etc/rc.d/rc.cache_dirs stop" Feb 27 08:08:27 Tower cache_dirs: killing cache_dirs process 7178 Feb 27 08:08:27 Tower rc.unRAID[31879][31901]: Running: "/etc/rc.d/rc.couchpotato_v2 stop" Feb 27 08:08:32 Tower rc.unRAID[31879][31968]: Running: "/etc/rc.d/rc.dnsmasq stop" Feb 27 08:08:32 Tower dnsmasq[7264]: exiting on receipt of SIGTERM Feb 27 08:08:32 Tower rc.unRAID[31879][31971]: Running: "/etc/rc.d/rc.dovecot stop" Feb 27 08:08:32 Tower rc.unRAID[31879][31976]: Running: "/etc/rc.d/rc.fan_speed stop" Feb 27 08:08:32 Tower rc.fan_speed: WARNING: fan_speed called to stop with SERVICE not = disabled Feb 27 08:08:32 Tower rc.unRAID[31879][31985]: Running: "/etc/rc.d/rc.logitechmediaserver stop" Feb 27 08:08:32 Tower rc.unRAID[31879][31988]: Running: "/etc/rc.d/rc.minidlna stop" Feb 27 08:08:32 Tower rc.unRAID[31879][31991]: Running: "/etc/rc.d/rc.mpop stop" Feb 27 08:08:32 Tower rc.unRAID[31879][31993]: Running: "/etc/rc.d/rc.mysql stop" Feb 27 08:08:33 Tower rc.unRAID[31879][32027]: Running: "/etc/rc.d/rc.mysqld stop" Feb 27 08:08:33 Tower rc.unRAID[31879][32034]: Running: "/etc/rc.d/rc.transmission stop" Feb 27 08:08:35 Tower rc.unRAID[31879][32055]: Stopping unRAID. Feb 27 08:08:35 Tower mountd[6488]: Caught signal 15, un-registering and exiting. Feb 27 08:08:36 Tower rc.unRAID[31879][32078]: Killing active pids on the array drives Feb 27 08:08:36 Tower kernel: nfsd: last server has exited, flushing export cache Feb 27 08:08:36 Tower rc.unRAID[31879][32082]: Synching data Feb 27 08:08:37 Tower rc.unRAID[31879][32086]: Umounting the drives Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: /dev/md1 umounted Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: /dev/md2 umounted Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: umount2: Device or resource busy Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: umount: /mnt/disk3: device is busy. Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: (In some cases useful info about processes that use Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: the device is found by lsof( or fuser(1)) Feb 27 08:08:37 Tower rc.unRAID[31879][32090]: umount2: Device or resource busy Feb 27 08:08:38 Tower rc.unRAID[31879][32090]: /dev/md4 umounted Feb 27 08:08:38 Tower rc.unRAID[31879][32090]: /dev/md5 umounted Feb 27 08:08:38 Tower rc.unRAID[31879][32095]: Stopping the Array Feb 27 08:08:38 Tower rc.unRAID[31879][32101]: /root/mdcmd: line 11: echo: write error: Device or resource busy Feb 27 08:08:38 Tower kernel: mdcmd (26): stop Feb 27 08:08:38 Tower kernel: md: 2 devices still in use. I will try reverting to minidlna 1.0.25 and see what happens. My suspicion is that I will still get the failed dismount - I think that something has changed about the way that powerdown v2 is dismounting - perhaps v1.02 waited longer, or did more retries? Certainly, when I stop the array from the emhttp interface, the system sometimes does several retries before all the drives dismount ... but it never fails. Of course, there is one significant difference between a 'powerfailure' powerdown and an emhttp 'stop' - that is that my photoframe (dlna client) will still be active in the second case while, in the first case, the photoframe will have turned off five minutes before powerdown is invoked.
February 27, 201412 yr Author I will try reverting to minidlna 1.0.25 and see what happens. My suspicion is that I will still get the failed dismount - I think that something has changed about the way that powerdown v2 is dismounting - perhaps v1.02 waited longer, or did more retries? The latest version of minidlna is not the problem. Powerdown V2.xx is very different than V1.02 and the sequence leading up to the unmounts has changed to be more in line with how unRAID should be shut down. Please re-download the V2.05 package and lets look at the logs when you have a power outage. I've added some additional information to the log that should tell us what is holding up the unmounts of md3. The easiest way to do this is to delete the powerdown package from the /boot/packages directory and then reboot.
March 1, 201412 yr Author Powerdown Version 2.06 is available on the GitHub repository. This is considered a stable release. Please read the OP for information on powerdown installation and use.
March 1, 201412 yr Powerdown Version 2.06 is available on the GitHub repository. This is considered a stable release. Please read the OP for information on powerdown installation and use. dlandon, thanks for making this improved version of powerdown available to all of us. This powerdown v2.06 package will be automatically installed when people upgrade to Dynamix webGui version 2.2.2. So no need for people using Dynamix to do a separate installation (courtesy of dlandon).
March 3, 201412 yr So what happens if I am running the apc ups plugin?? will it overwrite the new included in dynamix powerdown or will it use the dynamix powerdown or do I still need to modify the apc plugin to download the new powerdown package???
March 3, 201412 yr Author So what happens if I am running the apc ups plugin?? will it overwrite the new included in dynamix powerdown or will it use the dynamix powerdown or do I still need to modify the apc plugin to download the new powerdown package??? Dynamix will install first and install powerdown 2.06. Then the apcupsd will install and overwrite the powerdown 2.06 package with the package it loads. This is a case of who installs last wins. It's best to have the apcupsd powerdown package the same as Dynamix - in this case version 2.06 of the powerdown package.
March 3, 201412 yr Thx Now, that it's final, how can I install it when I'm using unMENU so that it does not conflict? @nicinabox Will this be included in ControlPanel? Then the above question is obsolete.
March 3, 201412 yr Author Thx Now, that it's final, how can I install it when I'm using unMENU so that it does not conflict? @nicinabox Will this be included in ControlPanel? Then the above question is obsolete. Powerdown is installed by Dynamix and apcupsd (for unRAID 5.x). Either of those will install powerdown and you won't need to use unMenu to install powerdown. I don't think apcupsd for v6 has been updated yet for the latest version of powerdown. The OP has information on how to update it manually.
March 3, 201412 yr I have unMENU installed already. Don't think I'm going to install dynamix just to have this up-to-date. Will check the OP for information.
March 4, 201412 yr I am running running unRAID 6 beta3 with Xen using a single VM. Stock unRAID except for the powerdown script, 2.06. I used Freddie's code from reply #122: [ -f /var/run/xenstored.pid ] && xl shutdown -a sleep 20 I am planning on more VMs in the future so this fits my needs well. Added it as a shell script within /boot/config/plugins/powerdown/rc.unRaid.d VM shuts down normally. unRAID shuts down normally, no parity check on power up. I'll add a S script to start my VM back up normally later. Now just need that APC addon to work with 6 and I'll be set! Many thanks to dlandon and everyone else that has helped in testing this. I will gladly continue to help with test.
March 4, 201412 yr Author I have unMENU installed already. Don't think I'm going to install dynamix just to have this up-to-date. Will check the OP for information. Maybe Joe L should update unMenu for the new Powerdown.
March 4, 201412 yr Author I am running running unRAID 6 beta3 with Xen using a single VM. Stock unRAID except for the powerdown script, 2.06. I used Freddie's code from reply #122: [ -f /var/run/xenstored.pid ] && xl shutdown -a sleep 20 I am planning on more VMs in the future so this fits my needs well. Added it as a shell script within /boot/config/plugins/powerdown/rc.unRaid.d VM shuts down normally. unRAID shuts down normally, no parity check on power up. I'll add a S script to start my VM back up normally later. Now just need that APC addon to work with 6 and I'll be set! Many thanks to dlandon and everyone else that has helped in testing this. I will gladly continue to help with test. Use xl shutdown -a -w and you won't need the sleep. The -w parameter waits for all VMs to be shut down. I think apcupsd for v6 has been updated.
Archived
This topic is now archived and is closed to further replies.