jang430 Posted July 2, 2015 Share Posted July 2, 2015 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? Quote Link to comment
danioj Posted July 2, 2015 Share Posted July 2, 2015 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. Quote Link to comment
jang430 Posted July 2, 2015 Author Share Posted July 2, 2015 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. Quote Link to comment
JonathanM Posted July 2, 2015 Share Posted July 2, 2015 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. Quote Link to comment
jang430 Posted July 2, 2015 Author Share Posted July 2, 2015 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. Quote Link to comment
danioj Posted July 2, 2015 Share Posted July 2, 2015 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. Quote Link to comment
JP Posted July 3, 2015 Share Posted July 3, 2015 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. Quote Link to comment
trurl Posted July 3, 2015 Share Posted July 3, 2015 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 Quote Link to comment
JP Posted July 3, 2015 Share Posted July 3, 2015 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. Quote Link to comment
trurl Posted July 3, 2015 Share Posted July 3, 2015 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. Quote Link to comment
JP Posted July 3, 2015 Share Posted July 3, 2015 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 Quote Link to comment
BRiT Posted July 3, 2015 Share Posted July 3, 2015 Syslog information is required too. Nothing crazy stood out on the ps list but i just gave it a quick glance. Quote Link to comment
JP Posted July 3, 2015 Share Posted July 3, 2015 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 Quote Link to comment
bonienl Posted July 4, 2015 Share Posted July 4, 2015 ... 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. Quote Link to comment
Hoopster Posted July 4, 2015 Share Posted July 4, 2015 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? Quote Link to comment
sekrit Posted April 6, 2019 Share Posted April 6, 2019 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? Quote Link to comment
quarkeddev Posted November 4, 2019 Share Posted November 4, 2019 (edited) 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, 2019 by quarkeddev Quote Link to comment
Recommended Posts
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.