July 2, 201511 yr Hi. I tried to install binhex's sonarr while I still have a few docker apps running in the background. Sab, Sickbeard, Couchpotato. All of a while, the reloading sign on browser stopped with no new activity. Reloading the web ui url of unraid is no longer working. All my apps are still running. Is there a way to restart the web ui without restarting unraid? Once I restart docker, it will automatically do a parity check. Is thie the convention? How do I disable parity check on startup selectively?
July 2, 201511 yr Hi. I tried to install binhex's sonarr while I still have a few docker apps running in the background. Sab, Sickbeard, Couchpotato. All of a while, the reloading sign on browser stopped with no new activity. Reloading the web ui url of unraid is no longer working. All my apps are still running. Is there a way to restart the web ui without restarting unraid? Once I restart docker, it will automatically do a parity check. Is thie the convention? How do I disable parity check on start up selectively? I'd be interested in this too. The GUI "not responding" plagues users in various situations and has done across multiple versions of unRAID. I got around this in the past by installing the unMENU. When the GUI went down - which unfortunately is often - I was still able to pull a syslog and see what was going on! I was trying to stay away from the command line and use unRAID the way it was intended but I have resigned myself to the fact that using the command line with unRAID is pretty much compulsory *shrugs*. Not sure if unMENU works with v6 - as like I said, I just use the command line now. Anyway - to help you - I find that finding the process that is "hanging" the GUI is the best method to solving these issues. Find it and decide. Kill it or wait for it to complete. Usually (if you're patient) the process will finish and the GUI will become responsive again. But if you're not patient. telnet into your system ps -ef This will bring back a list of processes running. Usually you can observe the last running processes and one of these is usually the one that is hanging the GUI. I find it is often easy to figure out which one it is. For example the last few times for me has been "Unassigned Devices" doing a mount or unmount which has hung things. Kill that process and boom, GUI is back and responsive again. I have also killed docker or kvm in the past too if I felt it was one of those the culprit. If you're brave, decide which process you think is hanging the gui and use kill <process_id> to kill it. I do find however that just waiting and going to grab a cuppa and coming back later is often the best method. I only use the above as a last resort or if I am in a hurry. Usually things work out and the GUI comes back if you just let things play out.
July 2, 201511 yr Author Thanks. But I'm afraid I literally prepared, drank and finished a cup of tea, and it still isn't there I don't see any unmenu for unraid 6 yet. So no need to issue command to restart interface? I mean I will kill the offending process, of course. That is if I can find it.
July 2, 201511 yr So no need to issue command to restart interface? Webgui is not restartable after it is killed. It will either start responding after you kill the offending process, or you will have to restart the server.
July 2, 201511 yr Author danioj, Thanks for the advice. After killing some process, was able to access web already. jonathanm, Thanks. So really have to look around the processes and see the offensive ones.
July 2, 201511 yr danioj, Thanks for the advice. After killing some process, was able to access web already. jonathanm, Thanks. So really have to look around the processes and see the offensive ones. No problem.
July 3, 201511 yr This is a bummer. I just upgraded to 6.0 and have the webgui hang issue. On the monitor of the server it reflects: "sending signal arlm to pid 1337. Waiting for pid 1337 to exit." It has been 30 minutes and nothing.
July 3, 201511 yr Community Expert This is a bummer. I just upgraded to 6.0 and have the webgui hang issue. On the monitor of the server it reflects: "sending signal arlm to pid 1337. Waiting for pid 1337 to exit." It has been 30 minutes and nothing. What do you get from ps -f -p 1337
July 3, 201511 yr What do you get from ps -f -p 1337 Well, I rebooted from the keyboard and got the GUI back, but I just started a parity sync and now the damn GUI is gone again. However, now I have a blinking cursor at "Tower login:" Should I still enter the ps -f -p 1337 command? I'm not entirely sure what that does.
July 3, 201511 yr Community Expert What do you get from ps -f -p 1337 Well, I rebooted from the keyboard and got the GUI back, but I just started a parity sync and now the damn GUI is gone again. However, now I have a blinking cursor at "Tower login:" Should I still enter the ps -f -p 1337 command? I'm not entirely sure what that does. It was going to tell us what pid 1337 was, but since you rebooted no point.
July 3, 201511 yr It is down again though and my hope is that it is doing a parity sync, but of course you can't see if it is if you can't get in to the GUI. I did the ps -ef command and the results are attached. Does anything stand out that I should "kill" to get the GUI back? psef.txt
July 3, 201511 yr Syslog information is required too. Nothing crazy stood out on the ps list but i just gave it a quick glance.
July 3, 201511 yr The syslog is attached, but I had to get it from a telnet and copy it to the flash. Naturally, trying to use a browser to get to it just hangs. Is there any way to tell if the parity check is complete from telnet? Without the GUI I can't tell what is going on and I'm not sure I should force a reboot while the parity check is going on. syslog.txt
July 4, 201511 yr ... Is there any way to tell if the parity check is complete from telnet? Without the GUI I can't tell what is going on and I'm not sure I should force a reboot while the parity check is going on. You can do grep mdResync= /proc/mdcmd When this counter is zero there is no parity operation in progress.
July 4, 201511 yr I don't see any unmenu for unraid 6 yet. I am running unRAID v6.01 and the latest version of unMENU works with it just fine. I rarely use anything in unMENU anymore since the new Web GUI is so complete; however, like many I have it installed for emergency situations which, fortunately for me, have not yet occurred in unRAID 6. I used to see frequent web GUI hangs in unRAID 5, but, since moving over to v6 beginning with beta10, I have experienced a GUI hang just once. I have no idea what is causing yours to hang, but, there are several mentions in these forums of the Unassigned Devices plugin being a suspect. Are you running that?
April 6, 20197 yr On 7/1/2015 at 9:27 PM, danioj said: I'd be interested in this too. The GUI "not responding" plagues users in various situations and has done across multiple versions of unRAID. I got around this in the past by installing the unMENU. When the GUI went down - which unfortunately is often - I was still able to pull a syslog and see what was going on! I was trying to stay away from the command line and use unRAID the way it was intended but I have resigned myself to the fact that using the command line with unRAID is pretty much compulsory *shrugs*. Not sure if unMENU works with v6 - as like I said, I just use the command line now. Anyway - to help you - I find that finding the process that is "hanging" the GUI is the best method to solving these issues. Find it and decide. Kill it or wait for it to complete. Usually (if you're patient) the process will finish and the GUI will become responsive again. But if you're not patient. telnet into your system ps -ef This will bring back a list of processes running. Usually you can observe the last running processes and one of these is usually the one that is hanging the GUI. I find it is often easy to figure out which one it is. For example the last few times for me has been "Unassigned Devices" doing a mount or unmount which has hung things. Kill that process and boom, GUI is back and responsive again. I have also killed docker or kvm in the past too if I felt it was one of those the culprit. If you're brave, decide which process you think is hanging the gui and use kill <process_id> to kill it. I do find however that just waiting and going to grab a cuppa and coming back later is often the best method. I only use the above as a last resort or if I am in a hurry. Usually things work out and the GUI comes back if you just let things play out. But if the server cannot be accessed via ip address, preventing the reaching of the GUI... How do we Telnet in?
November 4, 20196 yr I am having similar issue with GUI being inaccessible. However steps noted here do not appear to work. My issue appears to that port 443 and 80 are not listening on the server. I have created my own thread regarding this here http & https ports not listening Does anyone know how to get ports 443 and 80 to listen on the server again? Edited November 4, 20196 yr by quarkeddev
Archived
This topic is now archived and is closed to further replies.