FS#64189 - [cockpit] Browser uses a lot of CPU and cockpit is unresponsive
Attached to Project:
Community Packages
Opened by rainer (raneon) - Sunday, 20 October 2019, 16:46 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Saturday, 26 October 2019, 15:51 GMT
Opened by rainer (raneon) - Sunday, 20 October 2019, 16:46 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Saturday, 26 October 2019, 15:51 GMT
|
Details
Since the upgrade to cockpit 205 the webinterface is
extremely unresponsive and it consumes a lot of CPU. I've
tested this with Firefox and Falkon, both have the same
issues. Closing Firefox is not enough, you need to even kill
it's web processes.
Steps to reproduce: Login to cockpit And the e.g. try to enter ssh key path or password |
This task depends upon
Closed by Massimiliano Torromeo (mtorromeo)
Saturday, 26 October 2019, 15:51 GMT
Reason for closing: Fixed
Additional comments about closing: cockpit-205.1-1
Saturday, 26 October 2019, 15:51 GMT
Reason for closing: Fixed
Additional comments about closing: cockpit-205.1-1
I can't test it right now but I will probably tomorrow.
[1] https://cockpit-project.org/blog/cockpit-multi-server-dashboard.html
To make cockpit and the dashboard work again, I had to downgrade both packages. So something is seriously wrong with this upgrade. I will check in the cockpit bug tracker if I can find some additional info.
Also, it's very unclear what process specifically is using the CPU.
Let me quote myself again: "Steps to reproduce:
Login to cockpit
And then e.g. try to enter ssh key path or password"
So there is nothing special that I have to do... I just use the dashboard with several machines that are connected but they need the ssh key and password.
Next quote: "Closing Firefox is not enough, you need to even kill it's web processes" => web is a process of Firefox.
Okt 24 21:24:14 pc1 cockpit-ws[284713]: Error sending data: Broken pipe
Okt 24 21:24:14 pc1 cockpit-ws[284713]: WebSocket from (null) for session closed
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received out of order middle message fragment
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received out of order inital message fragment
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received fragmented control frame
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received fragmented control frame
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received fragmented control frame
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received out of order inital message fragment
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received unfragmented message when fragment was expected
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received fragmented control frame
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: received out of order inital message fragment
Okt 24 21:24:31 pc1 cockpit-ws[284713]: Received invalid WebSocket response from the server
Okt 24 21:24:31 pc1 cockpit-ws[284713]: WebSocket from (null) for session closed
Could this be related to the security hardending mentioned here? https://cockpit-project.org/blog/cockpit-205.html
Maybe an existing installs require user intervention...
The option is behind a configure flag, meaning it's optional and it's supposed to work just as before.
I did intend to follow upstream anyway, so I just did, and I released cockpit-205-2.
Feel free to test it but I doubt it will make any difference. It works fine for me though.
I suggest to report upstream if you still experience those issues.
I understand that the focus here is on packaging. I assume that your setup is a single client installation, probably that's why it works. Thanks you
But as soon as I access it via the IP (for example 192.168.1.101:9090) it starts to behave strange. I login and will be kicked out again. So I press the button to reconnect, but same behavior, I will be kicked out again.
I've tried this with IPv4 and IPv6, same issue.
Would you please do me a favor and test this as well? With this single machine setup I do not believe I'm doing anything special now.