February 5, 201313 yr Ok, i was running rc5 and upgraded to rc11 On both versions, unraid was keep unmounting my disks when i stop my array I had to hard power it off...to shut it down.. I thought going to rc11 would fix it, but i guess not.. So this noon, after upgrading to rc11 i tried to to stop the array and again... Itkeptsaying unmounting disks... I turned it off with my case button, and just rebooted, thought i would show you syslog... Now i get the message it didnt shut down properly and before i start it again i wanted toshow the log... But it seems it didnt even create a log this noon when it froze again... Help needed.., should i just start and sho you current log? But then the freezong thing Wont be in it?
February 5, 201313 yr Ok, i was running rc5 and upgraded to rc11 On both versions, unraid was keep unmounting my disks when i stop my array I had to hard power it off...to shut it down.. I thought going to rc11 would fix it, but i guess not.. So this noon, after upgrading to rc11 i tried to to stop the array and again... Itkeptsaying unmounting disks... I turned it off with my case button, and just rebooted, thought i would show you syslog... Now i get the message it didnt shut down properly and before i start it again i wanted toshow the log... But it seems it didnt even create a log this noon when it froze again... Help needed.., should i just start and sho you current log? But then the freezong thing Wont be in it? It was attempting to un-mount the disks prior to cleanly stopping the array. If you saw repeated messages, then one or more of your disks was "busy" and could not be un-mounted. unRAID tries every few seconds to see if the disk is no longer busy. Those are the messages you saw. A disk is "busy" when a file on it is open (for reading or writing) or if it is the current directory of a process, or if it is a mount-point for a file-system, or the location of a swap-file. As an example... you are using the "cache" disk to keep an add-on execuitable... It is running... therefore, it is the current directory of that process and the cache disk cannot be un-mounted until that process terminates. Another example... if you had logged on via telnet, or via the system console and changed directory to /mnt/disk1, or /mnt/user/Movies (or to a location on one of your disks) your login session is keeping the disk busy. Most frequently it is an add-on that is keeping your disks busy. You can see the files and current directories at any given instant in time by typing lsof | grep /mnt Sample output from my server is: root@Tower:/# lsof | grep /mnt shfs 1475 root 4r REG 9,6 4428179456 9648 /mnt/disk6/Movies/FRANKENSTEIN.ISO smbd 21605 root cwd DIR 0,12 12208 541165890325 /mnt/user/Movies smbd 21605 root 25r DIR 0,12 12208 541165890325 /mnt/user/Movies smbd 21654 root 25r DIR 0,12 1360 377957199596 /mnt/user/Mp3 smbd 21654 root 32r DIR 0,12 4352 523986010118 /mnt/user/Pictures smbd 21654 root 34r DIR 0,12 12208 541165890325 /mnt/user/Movies smbd 21804 root 25r DIR 0,12 1360 377957199596 /mnt/user/Mp3 smbd 21898 root 30r REG 0,12 4428179456 274877916592 /mnt/user/Movies/FRANKENSTEIN.ISO smbd 21919 root cwd DIR 0,12 12208 541165890325 /mnt/user/Movies Usually, all most users will see is that "smbd" has as a current directory each of your user-shares. unRAID will terminate those "smbd" processes as the first step in its shutdown. You probably have something else active. If you have "cache_dirs" installed, it too will have a current directory process... it also has a periodic "find" process. In between each "find" process, it looks for those "unmounting" messages in the system log and will suspend itself if it sees them so the mount can proceed. Far more likely you have some add-on that does not stop itself. That was why the server was emitting those messages... It was waiting for you to cleanly stop your add-on. By power cycling your server, it experienced an un-clean shutdown. The system log (which is always in a RAM file-system) was lost. When you reboot, it will have to replay the file-system journels to get them back to where they can be used again. That can take as long as 30 minutes or more, but typically only takes a few seconds to a minute. (depends on the amount of disk activity prior to the un-clean shutdown) So... most-likely... you need to stop your add-ons prior to stopping the array. (or, of you logged in and changed directory to one of your disks, log off) Joe L.
February 5, 201313 yr Author Well im running these addons: sabnzbd, sickbeard, slimserver, dropbox, airvideo, and snap, i was about to install mysql again but didnt yet. Last addon i added was sickbeard.. How can i find out which one was running when i shut off? I mean, i cant look to test to see if ones running if im not sure it will hang.. Mmm Isnt there a way for the clean powerdown to stop all addons before trying to shut down or unmounting disks? I get this now, but not sure it will hang if i try to stop Smbd 18243 root cwd DIR 0,13 72 128849018884 /mnt/user/Concerten smbd 18243 root 25r DIR 0,13 72 128849018884 /mnt/user/Concerten dropbox 28910 nobody 4u REG 8,81 12288 32171 /mnt/cache/Apps/DropboxDB/config.dbx dropbox 28910 nobody 9u REG 8,81 239616 32200 /mnt/cache/Apps/DropboxDB/photo.dbx dropbox 28910 nobody 10u REG 8,81 15482880 32172 /mnt/cache/Apps/DropboxDB/sigstore.dbx dropbox 28910 nobody 12u REG 8,81 595968 32199 /mnt/cache/Apps/DropboxDB/filecache.dbx python 29030 nobody 1u REG 8,81 0 32192 /mnt/cache/Apps/Sabnzbd/logs/sabnzbd.error.log python 29030 nobody 2u REG 8,81 0 32192 /mnt/cache/Apps/Sabnzbd/logs/sabnzbd.error.log python 29030 nobody 4w REG 8,81 1462104 32813 /mnt/cache/Apps/Sabnzbd/logs/sabnzbd.log python 29030 nobody 6u REG 8,81 0 32192 /mnt/cache/Apps/Sabnzbd/logs/sabnzbd.error.log python 29312 nobody cwd DIR 8,81 280 14185 /mnt/cache/Apps/Sickbeard python 29312 nobody 3w REG 8,81 8613518 13886 /mnt/cache/Apps/Sickbeard/Logs/sickbeard.log root@Unraid:~#
February 5, 201313 yr It is not "hanging"... it is doing exactly what Lime-Tech coded it to do... wait for the processes using the disks to terminate. you seem to have three processes using your disks... Dropbox, Sabnzbd, and Sickbeard. unRAID will not stop until they are first stopped. Start a thread in the customizations forum asking for help in getting those to stop themselves in your server. In the same way, you need to ensure the server is online and running BEFORE starting them when you reboot, otherwise they will prevent the array from coming online. Good luck... but with add-ons comes responsibility to manage them. (start them AFTER the array is online, stop them BEFIRE the array is taken off-line. The object is to do it cleanly to prevent file corruption) Joe L.
February 6, 201313 yr Author It is not "hanging"... it is doing exactly what Lime-Tech coded it to do... wait for the processes using the disks to terminate. you seem to have three processes using your disks... Dropbox, Sabnzbd, and Sickbeard. unRAID will not stop until they are first stopped. Start a thread in the customizations forum asking for help in getting those to stop themselves in your server. In the same way, you need to ensure the server is online and running BEFORE starting them when you reboot, otherwise they will prevent the array from coming online. Good luck... but with add-ons comes responsibility to manage them. (start them AFTER the array is online, stop them BEFIRE the array is taken off-line. The object is to do it cleanly to prevent file corruption) Joe L. Well after that i tried to shut it down and it didnt "freeze" Guess it must be some other addon then, strange Isnt there a way to add something in the clean powerdown script, so it closes all addons before trying to take the array offline?
February 7, 201313 yr Author Well, i tried shutting down just sec ago, and again it "waits" This i got now: Linux 3.4.26-unRAID. root@Unraid:~# lsof | grep /mnt dropbox 16449 nobody 6u REG 8,81 12288 32171 /mnt/cache/Apps/DropboxDB/config.dbx dropbox 16449 nobody 12u REG 8,81 15482880 32172 /mnt/cache/Apps/DropboxDB/sigstore.dbx dropbox 16449 nobody 14u REG 8,81 239616 32200 /mnt/cache/Apps/DropboxDB/photo.dbx dropbox 16449 nobody 15u REG 8,81 595968 32199 /mnt/cache/Apps/DropboxDB/filecache.dbx dropbox 16449 nobody 24u REG 8,81 6144 17899 /mnt/cache/Apps/DropboxDB/deleted.dbx root@Unraid:~# Can i say the dropbox is causing it then?
February 7, 201313 yr Well, i tried shutting down just sec ago, and again it "waits" This i got now: Linux 3.4.26-unRAID. root@Unraid:~# lsof | grep /mnt dropbox 16449 nobody 6u REG 8,81 12288 32171 /mnt/cache/Apps/DropboxDB/config.dbx dropbox 16449 nobody 12u REG 8,81 15482880 32172 /mnt/cache/Apps/DropboxDB/sigstore.dbx dropbox 16449 nobody 14u REG 8,81 239616 32200 /mnt/cache/Apps/DropboxDB/photo.dbx dropbox 16449 nobody 15u REG 8,81 595968 32199 /mnt/cache/Apps/DropboxDB/filecache.dbx dropbox 16449 nobody 24u REG 8,81 6144 17899 /mnt/cache/Apps/DropboxDB/deleted.dbx root@Unraid:~# Can i say the dropbox is causing it then? Yes. Based on the directory names involved, I'd say it was dropbox. Stop it, and the array will stop.
Archived
This topic is now archived and is closed to further replies.