Jump to content

Webgui unresponsive


reluctantflux

Recommended Posts

I can access the web interfaces of all my dockers that are both bridge and host mode.  I can also access unmenu, just not the unraid gui.  Nothing new added to my system except a 8-bay icy dock cage last night for SSDs, and setting up a new Windows 10 VM that I'm currently using to post this.  I'm running Unraid 6 final.  I've had this issue in the past and just rebooted and done a parity check, but I would prefer to get to the bottom of it this time.  Attached is diagnostic.

 

I'm seeing a lot of this in the unmenu syslog

Jun 25 19:23:22 Tower dnsmasq-dhcp[7795]: DHCPREQUEST(virbr0) 192.168.122.213 52:54:00:89:2a:9a  (Network)
Jun 25 19:23:22 Tower dnsmasq-dhcp[7795]: DHCPACK(virbr0) 192.168.122.213 52:54:00:89:2a:9a WIN-SGJHS3RN0PM (Network)

 

Thanks for any help!

tower-diagnostics-20150625-2246.zip

Link to comment

I can't do that unless I reboot, in which case, I won't know which is the issue because the problem is pretty rare.  I think the plugins I'm running are cache_dirs, and a few of the dynamix system stat ones.  Other than that, everything else is dockers and vms.

 

ETA: Oh, and I am also running unassigned devices plugin. Forgot about him.  Saw someone else mention him causing webgui issues.

Link to comment

Bummer. Was hoping to help troubleshoot to resolve the problem for good. Any way to isolate emhttp service so it can be restarted without a full reboot?

Nope. emhttp handles part of the licensing, and my speculation is that Tom made it non-restartable on purpose or as a side effect of some change in the 5.0 series of unraid. Prior to that it was restartable, so you will find some threads about restarting it, but those methods no longer work.

 

The official answer is reboot, and don't use plugins that interfere with emhttp. If you wish to continue to use the offending plugin, it would be best to try to help the author of the plugin figure out what is causing the issue by posting for help in that plugin's thread.

 

It would be nice if emhttp were more robust and could kill the offending process and keep running, but that's not the way it is right now.

Link to comment

I was running preclear on a 3TB disk which ended this morning.It was a console session.Last night I installed openvpn-as container.I had to shutdown /boot/powerdown as the web was unresponsive.

It seems every time I fiddle by (adding a new one)with a docker container it "emhttp" seems to hit the roof.I did delete the openvpn-as container once as the /config path was not there or incorrect.

Link to comment
  • 6 months later...

I am running 6.1.3. Same thing happening with me. Lost webgui and access to file shares. Most container-based (docker) systems still work aok. Has happened maybe once every 6 to 8 weeks.

 

Containers:

  • Calibre-server (not responding)
  • CrashPlan (unsure)
  • SABnzbd (was AOK)
  • SickBeard (was AOK)
  • Transmision (was AOK)

 

Had to do a hard reset to get it back, which took ~10 minutes before the array started.

 

The only plug-in I have is OpenVPN Client. I just noticed that there is an update for OpenVPN Client: 2015.10.11 --> 2015.12.23

Also, as I am using Unraid 6.1.3 I will update to Unraid 6.1.7 as soon as the parity check completes.

 

Only posting in case it helps someone diagnose what is happening.

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...