Unexpected close while ready - novnc after 20 sec
Hi all, I have setup this nice product from master brunch on ubuntu 14.04, so, in Ubuntu 14.04 novnc doesn't have a daemon module, and there no command like this:
$ sudo service novnc stop $ sudo insserv -r novnc
Is it a normal?
So, my problem is about novnc, it closes any connection to vm after 15-20sec, every time. I don't have any proxy or SSL, just fresh install.
Can you help me with it?
There is no any kind of log for that.
Thank a lot for any help!
Hello,
I reproduce the same bug and after some hours of search, it's appear to be (in my case) a bug related with websockify/novnc libraries : when this libraries handle the SIGCHLD, the connection it's kill after some seconds. If I comment the lines witch handle this signal, the connection work fine. You could try this work around by editing websocket.py file, search and comment this lines :
if not multiprocessing:
# os.fork() (python 2.4) child reaper
signal.signal(signal.SIGCHLD, self.fallback_SIGCHLD)
else:
# make sure that _cleanup is called when children die
# by calling active_children on SIGCHLD
signal.signal(signal.SIGCHLD, self.multiprocessing_SIGCHLD)
I still working on it, so if I found a better way to fix this issue, I will give you feed back.
Thank a lot for a your investigation for this bug. I have changed file (ubuntu 14.04): /usr/lib/python2.7/dist-packages/websockify/websocket.py , NOT: /usr/lib/python2.7/dist-packages/novnc/websocket.py
After changle it looks like OK! I hope it'll be fixed by a normal way rather than this workarround.
THANK YOU AGAIN, for your spent time for that!
Like I say, I still working on it. I find that it's when connection is make over SSH tunnel that we have this issue. In fact, it's seam to be the SSH process (running to tunneling the connection) that is dies and resulting process receive a SIGCHLD. Tunnel library don't handle this signal while websockify handle it and it cause that all the stack in place for the client connection is killed.
When disabling SIGCHLD handling, it should causes some zombie process. In fact, in must cases, the SSH process will automatically ending when web user disconnect. But, on my workstation, I have actually 13 SSH zombie process...
I found a lot of relative bug report in differents projects using SSH tunneling : certain appear to be magically resolved and some other is unintelligible for me. So, I have currently no solution for this issue.
Dear brenard, it is a very interesting story about ssh tunnel. I'm very sadly but I can't help you with it. I work just as a system administrator and I don't have any experience with programming.
Thank you. I hope this problem will give you new skills.
Best regards, Victor.
@GusevVictor : no problem, I say that for all other devs witch could transit by this issue ;) Thanks for your return, it's one way to help free software to progress ;)
@brenard Is there any progress on this issue yet?
@WhiteIntel No, I didn't found any time to work on it. The work around fix the problem for you ?
@brenard I´m using spice but when I commented the lines you suggested I´m not able to connect.
@retspen Any idea?
I'd like to add that I am having this issue also. noVNC disconnects after exactly 30 seconds when running websockify from webvirtmgr-console (i.e. the recommended way of doing things). I do NOT have this problem when I run websockify from the command line: websockify 0.0.0.0:6080 vmhost:5900
I am not doing an SSH tunneling.
I've done some bug hunting. The error lives in webvirtmgr-console around line 137:
try:
self.msg("Start proxying")
self.do_proxy(tsock)
self.do_proxy(tsock) hangs after 30 seconds and doesn't go any farther. Okay so what's do_proxy?
Thats in /usr/lib/python2.7/dist-packages/websockify/websocketproxy.py or wherever it lives for you. The "hang" happens line 136: ins, outs, excepts = select(rlist, wlist, [], 1) This call runs successfully a bunch of times in a while True but eventually throws a exception: select.error error: (4, 'Interrupted system call')
...and I have no idea why this happens :-)
I submitted a pull request to websockify that basically ignores the issue - which in this case, is kinda a reasonable thing to do. I'm not sure exactly where the issue is: websockify or webvirtmgr, but if my pull goes through over there, I'd recommend closing this bug. See here for more: https://github.com/kanaka/websockify/issues/166
The pull request of @bkanuka was merged : https://github.com/kanaka/websockify/issues/166
We have to check that upstream version of websockify fix this issue and I hope, we could close it.
Well I updated websockify to the latest version (0.6.1) and now I´m not able to connect anyway:
Error with spice:
Error: Unexpected protocol mismatch.
at WebSocket.
I am still having this issue. I get disconnected after 30 seconds. I am not using a proxy or SSL. I checked that I have the changes suggested by brenard, and I am still having the issue. Is this resolved for everyone else?
The issue still exists on my server too. Still annoying and still no fix for that. On Jul 20, 2015 4:02 AM, "kkasberg" [email protected] wrote:
I am still having this issue. I get disconnected after 30 seconds. I am not using a proxy or SSL. I checked that I have the changes suggested by brenard, and I am still having the issue. Is this resolved for everyone else?
— Reply to this email directly or view it on GitHub https://github.com/retspen/webvirtmgr/issues/503#issuecomment-122729100.
I had the same issue. Upgrading to Websockify 0.7.0 (which got release a few days ago) via pip seems to have fixed it for VNC over SSH. I have not tried Spice.
pabbott0, thank you! It looks like a good solution.
No prob :) And thanks to websockify for fixing the issue. After trying Spice, it didn't seem to work properly. Then again, I don't think I've ever had Spice actually work for me using novnc on any other virt management interface (like oVirt), so no big deal.
I am still having it close after the 20 seconds. Is there anything that needs to be done after updating to Websockify 0.7.0?
I had the same issue too. Upgrading to Websockify 0.7.0via pip seems to have fixed it for VNC over SSH@pabbott0 thanks bro!