Attempted to post in WebGUI design under programming, but this is the next best topic that I can find, "Defect Report", which may be more appropriate as it is an issue with CHRONIC failure of the WebGUI, albeit intermittently... although the 'symptoms' appear to be the same.  In anywhere from three days to three hours, the WebGUI will "go out the 'Window'".  (unRAID 6.3.5 connecting with IE 11 or Chrome in Windows 7 Pro)  The GUI will become unresponsive (if the browser was left open) or will not connect at all; COMPLETELY UNRESPONSIVE.  Yet, most of the time the shared network connection is still working, the server appears on the network, can ping (by name or IP), and can Telnet.  It is essentially the GUI that is always acting up.  I've read everything I can find online regarding this, which appears to be pretty substantial and occurs within the Lime Tech Community quite often from what I've gathered.  What has not been provided is ANY methodology which works to restore the functionality of the GUI - short of having to reboot the system, causing a real PIA when it spends the next FIVE HOURS (on drives are only 1/4 used) doing a parity check because it "detected an unclean shutdown" (using "reboot", or "shutdown", or depressing the power switch); doesn't much matter.  Half of the time when it reboots it runs a parity check.  DOES ANYONE HAVE A RESOLVE FOR THIS, KNOW A WORK-AROUND, OR EVEN A REPLACEMENT FOR THE DEFECTIVE GUI?

I actually very recently had the very same problem and I was on 6.4.0_rc10b.

For me it started parity everytime, emhttp said that too many files are open and gui never came back. 

Fixed it by formating the USB stick and reinstalling the stick with fresh Unraid.
(If you decide to do it remember to write down everything essntial: Array disks order [Don't know how to get it from terminal] - copy the key file from USB stick etc)
If I were you I'd copy the USB stick to PC and then reinstall fresh install and if you forget something you can simply recopy the last one. 

Thanks for the input Southweave... Yea, I found out early on that a corrupted flash drive could be a culprit.  I scanned mine and found it to be intact.  Certainly it should be noted as a possibility for other members to look at if they are experiencing this problem.  I think I've gotten to the root of mine - another item that forum members might find of interest in relation to this 'bug'.  It can relate to memory - and I don't mean defective memory that might screw-up anything that runs on the system. (Yes, I checked mine with MemTest86+ and it all passed.) I'm talking about amount of memory and what is 'recommended'.  I put together a basic system in lieu of going the pre-fab route, and I certainly checked into the 'requirements' for the use it was to be put to.  I even monitored the system for days on end to see that none of the usage exceeded the system capabilities - it didn't.  unRAID booted, approx. 51% memory usage, array started with parity check, about 58%.  "Up and running" - not over 63% AND IT STILL FAILED.  I had stopped running the only app that was really being used (other than a couple of Community Apps), Plex Media Server, which NEVER EXCEEDED 82% of memory usage.  However, I ran unRAID alone just to isolate the problem.  Now, here is where it gets interesting.  I'm waiting on more memory to really get this puppy going, but in the meantime I threw in an 'extra' stick I had (normally a bad idea as it puts the kibosh to dual-channel throughput) and guess what?  Running the same unRAID and PMS, usage exceeded 100% of the original amount of memory! (I only increased it by 50%)  SAY WHAT?!!!  Yea, you heard right.  I had NEVER seen it exceed 82% of available memory BEFORE, but after increasing available memory by 50%, it used over 100% of the original amount of memory to run the EXACT SAME CONFIGURATION (unRAID and PMS). AND, the WebGUI has only failed  once since then...  interesting "coincidence", huh?

(Yea, now unRAID just crashes altogether, without ANY excuse at all - I'm in a 'constant' state of parity checking.)

Edited November 12, 20178 yr by CaryV
Current state of affairs

I think so. It's very wrong

On 11/11/2017 at 9:12 AM, CaryV said:

Yea, now unRAID just crashes altogether, without ANY excuse at all - I'm in a 'constant' state of parity checking.

 

Constant crashes are certainly not the norm, in general unRAID is very stable.

 

Post your diagnostics once you experience a 'crash'.

 

Edited November 13, 20178 yr by bonienl

Here's the diagnostics...

I stopped leaving the web browser open, but the server was still running (not much good as a server if it wasn't).

It crapped-out entirely - still running, but TOTALLY unresponsive; not as much as an IP address.

Had to do a 'hard' boot to get it running again;

I happened to start the array (parity checking for the next five hours) just before running "diagnostics"

(Hope that doesn't affect them - if so, I can re-run without starting the array upon the next 'crash'.)

 

Thanks for any assistance you can provide,

Cary

 

headless-diagnostics-20171114-2226.zip

Edited November 15, 20178 yr by CaryV

Two things you can do

 

1. You are loading several plugins of which I am not sure they are all compatible with unRAID6.3. Start your server in safemode for now.

2. The BTRFS file system of your cache drive detects issues and causes problems in libvirt (VM manager). You'll need to repair the cache FS. You can start doing it from the GUI, but if more action is required perhaps @johnnie.black is willing to assist, he is the true expert.

28 minutes ago, bonienl said:

The BTRFS file system of your cache drive detects issues and causes problems in libvirt (VM manager). You'll need to repair the cache FS.

 

Just a quick syslog look but not seeing any issues, if you refer to this it's just a warning and harmless:

 

Nov 14 22:25:25 Headless kernel: BTRFS warning (device sdc1): block group 20971520 has wrong amount of free space
Nov 14 22:25:25 Headless kernel: BTRFS warning (device sdc1): failed to load free space cache for block group 20971520, rebuilding it now

 

OK guys - here's the story...

I restarted the system after a "crash" (and began the five hour parity check).

Got up this morning to find it "crashed" AGAIN!

(Did I say "constant" parity check - maybe that should be "perpetual"; that's just how bad it is.)

Crash in my case is defined to be that the server is still running, but unRAID is "dead in the water" -

not as much as an IP address.

 

I'm looking on the webMENU (system is running "Headless") and don't see any "Boot to Safe Mode option".

 

I've got some new (other) memory now and will be kicking it up to 4GB (from 1.5), as well as a 2-core Opteron

that I'll be installing to replace (an outdated) single core processor...

the system will be pretty much 'maxed' at that point.

I mention this because it may effect unRAID functioning - although there is no indication of a hardware issue as it stands.

 

I take it then that there is no indication of the particular issue with unRAID, or what the issue might be?

(Save for a btrfs error that apparently is 'correcting itself' - what's going on that it's causing 'itself' such a problem?)

 

Anything I'm supposed to do at this point?

 

Perpetually yours,

Cary

 

Did get another "diagnostics" before starting the unRAID array this time; if it's of any benefit.

 

headless-diagnostics-20171115-0948.zip

On 11/15/2017 at 7:17 PM, CaryV said:

Anything I'm supposed to do at this point?

 

Start unRAID in safemode.

Just a note about memory consumption - Linux adapts the size of quite a number of internal data structures based on amount of RAM. So a machine with more RAM will consume more RAM just to boot. But it will on the other hand be ready to handle more work.

 

Do you have any monitor connected to your system, so you can see if it has written any error messages to the console when it locks up?

No, no monitor - hence "Headless".  Any error message would be found in the diagnostics.

 

What I alluded to in the explanation of memory usage has pretty much been proven to be true...

Despite the "minimum" requirements for unRAID (as specified for v6) having been met or exceeded (cpu, memory, etc.),

system dysfunctions were rampant - continual GUI failures and system crashes ALL taking place on perfectly good hardware.

Since applying the "upgrades" that I mentioned, the system has become stable, running without any further failure since last discussion.

Which leads to a very interesting conclusion - if the "minimum" requirements are not WELL exceeded, problems can ensue.

As indicated, even 50% more than 'minimum' memory didn't do the trick - just went from webGUI failure to system crashes.

 

I hope any else who is new to unRAID has a chance to see this - I spent a lot of time 'chasing my tail', listening to (untrue) revelations of 'bad' hardware

that I was pretty much dismissive of, but nonetheless spent the time to check-out; only to find that it had NOTHING to do with any 'bad' hardware...

Same mainboard, power supply, hard drives, flash drive, etc. in the same case - all now working by increasing available memory WELL beyond "minimum" requirements.

(ALL memory, before and after, having passed "memtest".)  As well as the fact that the CPU is now DOUBLE the Passmark evaluation that it was before - an additional factor that can't be ruled-out as contributing to a stable environment as it was upgraded at the same time - the objective not being to 'troubleshoot' any short-comings of unRAID or its components (as would be the case with applying upgrades separately), but just to have a completely functional OS that can be relied upon to do a job.