6.0 GUI unresponsive


Recommended Posts

I just had a frustrating day of troubleshooting with this but I think I've found the culprit. I was getting a freeze only seconds after connecting to the GUI.

 

I removed a USB TV Tuner that was being passed through to an Ubuntu VM. After removing the tuner and disabling VMs it all is working again.

 

Hope this helps someone.

 

James

Interesting. So you were passing through the tuner by clicking the check box for it on the VM page, right?

 

Yep. As far as I could see the VM wasn't starting properly either.

 

James

 

Link to comment

Good afternoon fellow unRAIDer's!

 

I have also experienced the hung-UI and forced ungraceful reboot from command line to restore operation.

shutdown now -r

 

ver: 6.0.1

 

Plugins: (all up-to-date as of this post)

1. Preclear Disks

2. Dynamix System Temperatures (which also requires PERL initially)

3. Dynamix System Statistics

4. Nerd Tools

5. Dynamix webGUI (stock)

6. unRAID Server OS

 

Docker enabled:

1. Plex Server (lime-tech repo) (up-to-date)

 

VM's not enabled yet.

 

Cache Pool: 4x 500 GiB Samsung_EVO

 

Correlated activity at time of hang: I had just wrapped up a StorageCraft Shadow Protect back-up of a workstation to an SMB share that uses cache on the unRAID server. There were 6 files ~500 GiB in the cache after the back-up.  I am trying to set up scheduled mover timing and parity checks, so I manually initiated a "Move Now" via the web UI to determine how long it would take to move the ~500 GiB from the cache to the array.  Everything seemed to be progressing normally, and it appeared that the mover had just wrapped up sending the last, and largest file (~300 GiB) to the array when the UI hung. Partial log below, I was just watching the logger entries via the "Log" window available from the UI.

Jul 4 21:23:31 MiniTower logger: ./SHADOW/WIN7U64/BCK/C_VOL-b042.spf
Jul 4 21:23:31 MiniTower logger: .d..t...... ./
Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/
Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/WIN7U64/
Jul 4 21:23:31 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/
Jul 4 21:23:31 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/C_VOL-b042.spf
Jul 4 22:12:19 MiniTower logger: ./SHADOW/WIN7U64/BCK/C_VOL-b042.md5
Jul 4 22:12:19 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/
Jul 4 22:12:19 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/C_VOL-b042.md5
Jul 4 22:12:20 MiniTower logger: ./SHADOW/WIN7U64/BCK/D_VOL-b042.spf
Jul 4 22:12:20 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/
Jul 4 22:12:20 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/D_VOL-b042.spf
Jul 4 22:12:54 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 22:19:22 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 22:46:42 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 22:52:08 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 23:03:55 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 23:23:21 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 4 23:24:06 MiniTower logger: ./SHADOW/WIN7U64/BCK/D_VOL-b042.md5
Jul 4 23:24:06 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/
Jul 4 23:24:06 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/D_VOL-b042.md5
Jul 4 23:24:11 MiniTower logger: ./SHADOW/WIN7U64/BCK/I_VOL-b042.spf
Jul 4 23:24:11 MiniTower logger: .d..t...... SHADOW/WIN7U64/BCK/
Jul 4 23:24:11 MiniTower logger: >f+++++++++ SHADOW/WIN7U64/BCK/I_VOL-b042.spf
Jul 4 23:50:02 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 5 00:24:52 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Jul 5 01:01:51 MiniTower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1

The last log entry posted back to the UI is listed above. Sorry I didn't grab the full log as I was only tracking the mover times and didn't expect a UI hang.

 

Probable red-herring: Just before the hang in the UI (~10 mins before) I was attempting to connect to the webUI from an Xbone (Xbox One) browser session to attempt to access the Plex server via that method. The UI "mostly worked" in the version of IE on Xbone, but there were some strange artifacts, and I could not access the Docker UI via this method. I then went back to a Debian (Wheezy) workstation to get the Plex server's URL to try a direct connection.  This occurred right as the webUI hung up.

 

Too many variables, I know. I think the webUI hang is most likely related to the mover operation however, because of the timing.  Too much correlation there to ignore.

 

Unfortunately, I did not find the instructions for running a diagnostic nor checking for hung processes until I had rebooted the box, so I don't have that info to post up at this time. If this happens again, I will certainly grab the hung diagnostic at that time.  The ssh session, all shares, and the docker (only have Plex set up) on the unRAID box was fine during the UI hang. The hang appeared to be limited to the web UI.

 

Per other threads that mentioned just "waiting it out",  I disconnected the web-UI session and let is stew over-night (~10 hours). It was still hung-up before I initiated the shutdown via the command line (~10 hours after the initial hang). No SMART errors on any of the 18 array disks, parity re-check still in-progress.  Sure wish I had found this thread first!

 

This brings me to the actual question that started the forum search to begin with:

 

1. What is the best way to perform a clean shutdown and reboot via the command line? I would like to avoid unnecessary parity checks (which take 36 hours on my box) if possible.  I see references to a "powerdown" plugin but every thread that I found (except for this one) that mentions that plugin is from ~2008 - 2009 and does not appear to apply to version 6.x (at least not directly).  I did use the powerdown plugin on my old 5.x unRAID box. Is there a link to the plugin for version 6.x that I just missed with my forum and google foo? If someone has a link to the current powerdown plugin that is compatible with version 6.x, a nudge in the right direction would be *greatly* appreciated!

 

This looks to be a *tremendous* upgrade with astounding potential!  Just need a way to restart the UI from the command line, and/or execute a clean shutdown and reboot to bring it back up!

 

Thanks for your time and efforts on out behalf!

 

 

Link to comment

Just need a way to restart the UI from the command line, and/or execute a clean shutdown and reboot to bring it back up!

As mentioned, I'm using the stop script by JoeL (http://lime-technology.com/forum/index.php?topic=2781.0, 3rd post down) to stop my array from a command line before running "reboot".  This brings my system back up without a parity check, but I'm unsure as to whether the script is still current.

 

I haven't created a new post yet personally, as the UI hasn't stopped on me since 6.0.1 (touch wood).

Link to comment

There is a powerdown plugin that explicitly supports version 6 and also version 5. It has a huge support thread even.

Thanks for the nudges guys.  I loaded up the 'powerdown' plugin per the instructions in this thread: http://lime-technology.com/forum/index.php?topic=31735.msg288775#msg288775

 

@BRiT: Is that the plugin thread you were referring to?  (I was looking at another thread with a 2008 date, which had me thinking it wouldn't be current for v6: http://lime-technology.com/forum/index.php?topic=812.msg11124#msg11124). turl's forum search tips located the newer one pronto!

 

 

@trurl: Thanks for the forum search methods. Indeed it isn't obvious that the search is tied to the current forum/sub-fourm level!

 

Is there a safe way to kill and restart the web UI via ssh or console so a reboot isn't necessary if/when the UI hangs again?

 

 

 

Link to comment

Is there a safe way to kill and restart the web UI via ssh or console so a reboot isn't necessary if/when the UI hangs again?

 

No,  the Web UI is not restartable in v5 or v6. It's something that would be nice to be able to do, to have the UI just be a UI and restartable.

 

And yes, the search ability isn't that straight forward here.

Link to comment

I hope this feedback gets to developers because it might give some indication of where the issue is.  IE and Firefox will freeze for me using the GUI on more than one PC.  It only takes about 5 - 10 mouse clicks navigating through the GUI.  However, as luck would have it, I have a Nexus 10 Android tablet with Chrome installed on it.  I noticed after maybe 100 navigating clicks through the GUI it wasn't hanging.  I installed Chrome on a PC and it hasn't hung yet either.  However, I turn back to IE or Firefox and it will hang in no time.  When that happens Chrome and nothing can access the GUI and I'm forced to powerdown to get it back.

 

It is very odd behavior, but I'm just thankful to have a way to navigate through the GUI now as well as powerdown safely if needed.

Link to comment

When the GUI becomes unresponsive, it might be that emhttp is waiting for another process to finish.

 

In case this happens again to you, can you post the output of the following commands before rebooting

ps -ef
lsof -Pni

 

It is attached.  Unfortunately, my new box is pretty good test server for this issue.  I can easily re-create in IE and Firefox for some reason.

GUI_Freeze.txt

Link to comment

For what it is worth, I was using Chrome (latest) from a Win 7 box when the hang/freeze happend in my scenario. *BUT* just prior to the hang I had in Chrome, I was trying to access the UI from the IE (cousin of IE 10) that is on Xbox One...  Too many variables so far.

 

 

 

Link to comment

When the GUI becomes unresponsive, it might be that emhttp is waiting for another process to finish.

 

In case this happens again to you, can you post the output of the following commands before rebooting

ps -ef
lsof -Pni

 

It is attached.  Unfortunately, my new box is pretty good test server for this issue.  I can easily re-create in IE and Firefox for some reason.

 

These lines

emhttp    1864   root    5u  IPv4  28772      0t0  TCP 192.168.1.110:80->192.168.1.120:53281 (CLOSE_WAIT)
Plex      5144 nobody   56u  IPv4  23630      0t0  TCP 127.0.0.1:55816->127.0.0.1:33122 (CLOSE_WAIT)

Signifies that emhttp is waiting for another process to finish and it looks like Plex is having a communication problem (seems you are running the plugin version).

 

For testing purposes you can uninstall the Plex plugin and see if that makes a difference.

 

Link to comment

Signifies that emhttp is waiting for another process to finish and it looks like Plex is having a communication problem (seems you are running the plugin version).

 

For testing purposes you can uninstall the Plex plugin and see if that makes a difference.

 

I don't think PLEX is a plugin.  It was installed via Docker.  I want to say these freezes happened right when I built the NAS with no plugics or dockers, but I can try some time and see if it helps.  Thanks again.

Link to comment
  • 1 month later...

When the GUI becomes unresponsive, it might be that emhttp is waiting for another process to finish.

 

In case this happens again to you, can you post the output of the following commands before rebooting

ps -ef
lsof -Pni

 

I've lost the GUI this morning.  it was taking a long time to respond, but not it's not responding at all...

 

results too large to post, so file attached.

GUI.txt

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.