I may have a reproducer / more info here using chrome version:
Chrome Version 74.0.3729.169 (Official Build) (64-bit)
With repeated:
“WebSocket connection to ‘’ failed: WebSocket is closed before the connection is established.” in Dev console.
Where as the same Rockstor install via:
Firefox 60.8.0esr (64-bit)
Works as intended. But I have seen some dashboard freezes but no Web-UI pauses or blank Web-UI top right.
Their is an intention to completely replace the way the dashboard works as it has tripped us up a few times in the past. But for this we need to move to Python 3 and Django 3: both non trivial tasks. All doable in time though.
Can folks having issues with 3.9.2-49 showing a mostly blank top right Web-UI and a bunch of empty dashboard widgets:
Chrome:
and some really annoying 10-30 second pauses upon visiting any page !!!
Please report your findings using Firefox.
Firefox:
If you find, having visited the Web-UI with Chrome, that the CPU load in Rockstor is consistently high their after (data-collector spinning away to itself), I have seen this once so far, then a reboot or possibly a rockstor.service stop start, as in my previous post, should calm things down again.
@Flox I’m also seeing this Chrome incompatibility on our pre-release testing channel openSUSE rpms so fairly generic problem.
My report of my installation working correctly was premature… it is working in firefox (but this has an existing browser cache. I’ll clear this shortly and retest) However in chrome which has never been used against my installation, exhibits the partial GUI problem. I also get the same issue when I test from an Android tablet.
If you would like any specific information, please let me know but it may take a day or two for me to respond. My environment, if this helps.
Client laptop running Fedora 30 :-
Firefox - 69.0.1 (64 bit) - Appears to be working, except that Web GUI is much slower than before and is causing firefox generate a high cpu load on my laptop. I am seeing the following recurring errors from the Firefox dev console (changed websocket IDs)
Firefox can’t establish a connection to the server at wss://rockstor/socket.io/?EIO=3&transport=websocket&sid=################. socket.io.js:6605:34
The connection to wss://rockstor/socket.io/?EIO=3&transport=websocket&sid=################# was interrupted while the page was loading. socket.io.js:6605:34
Chrome - Version 77.0.3865.90 (Official Build) (64-bit) - I am seeing the same errors in the dev console as reported.
My Rockstor server:
HP Gen 10 Microserver
Rockstor 3.9.2.49 however /etc/redhat-release still says “Rockstor release 3.9.23 (Core)”
Linux: 4.20.12-1.el7.elrepo.x86_64 (as latest Rockstor kernel is not compatible with this hardware)
Very high CPU usage by data-collector process
Recent updates
[root@rockstor ~]# yum history
Loaded plugins: changelog, fastestmirror
ID | Login user | Date and time | Action(s) | Altered
Yes firefox (android) looks fine and I is pretty snappy navigating the WebUI.
Chrome(windows or android) on the other hand is same as the OP and I had previously.
In firefox while the CPU load section does jump up to 95% initially. After a few seconds it seems to settle to ~5% with a few bumps up to 25% on one of the cores. Which with my Intel DN2800mt is pretty typical i believe.
Yes, no worries their. The updating of redhat-release and other os version indicators was never really maintained. We are to leave these alone in our comming openSUSE bases as it just caused incompatibilities when folks tried to compile/install stuff and unsurprisingly that stuff new nothing of “rockstor 3” etc.
Your Firefox report is currently an anomaly but is a new shiny version so that may be triggering something that looks pretty similar.
Try closing all browsers accessing your Rockstor box, reboot the rockstor box, then re-try with your version of Firefox.
Yes this is my experience on an openSUSE desktop system.
Yes, upon first visiting the Dashboard it does some yum / package checks and these often peak and then sustain a partial load on CPU but should then die off. 1% on moderate CPU cores is common for data-collector. But client CPU is hit pretty hard with our current dashboard.
Thank to all for your reports. I’m still not able to reproduce major slowdowns in Firefox and 3.9.2-49 should be noticeably more responsive than 3.9.2-48 and all for some time before it so any slowdown is most likely this browser python-enginio / gevent incompatibility or possibly quotas being re-enabled by a docker-ce install or the like. Normally only relevant on a re-install though and when then moving to our newer docker-ce from the prior version.
Linking for context to a prior pull request that ended up not being required as python-engineio ended up upgrading again and what problems we saw back then disappeared again. Looks like we may be hitting something similar again. This situation is complicated by our still using Python 2.7 so we do have some technical debt related issues here:
I’ll play with some of these library versions again and if a library pin or 2 works then I can roll out another stable rpm to hopefully get this sorted again.
If anyone else gets around to building from source to play with these library versions then do post here. I’m currently working on Web-UI upgrade within our openSUSE variants to help with moving in that direction but should be finished pretty soon. Their after I’ll have a look myself and if any joy will roll and release another stable rpm. My bet currently is on the same library pinning as was indicated in that pr of mine referenced above. So that’s probably where I’ll start when I’m done with my current task.
Apologies to all for the inconvenience, and the current work around looks to be:
“Use Firefox”,
at least mostly. But yes, almost all other browsers are webkit so we need to get this sorted.
Post here if you end up playing with source builds and newer / older library versions. But note that this should not be done on any production systems as a fresh source build will wipe the central Rockstor db.
A quick test here would seem to confirm your bet: pinning the version to 2.3.2 as per your PR #1996 seems to restore the header and dashboard activity (in chrome, after a clean source build):
I do not see any web socket error in Chrome dev console either (which I could reproduce prior to python-engineio version pinning).
I haven’t experienced high CPU usage by data-collector before so I can’t test whether these disappear as well, but given the header appears restored combined to the absence of websocket error, I would believe this would be fixed as well…
Still need more test to make sure nothing is broken but look like you were right.
I’ve now re-opened that pr and commented their that it has re-occured. Might as well re-use it as it has quite a bit of detail in. If further testing with this pinning pans out as OK, I’ll pop it in and do a quick openSUSE testing release and if that check out we can release another Stable version with this included.
Cheers for confirming this as a potential fix, if all is well we should have this sorted in the next few days. Thanks folks for the feedback. I’m looking forward to having a ‘proper’ testing channel again soon. More on that in time .
.