I've tracked down the problem and implemented a fix. The issue is that Xvnc in inetd mode detects whether it is run as "wait" or "nowait" by checking if the inetd socket has a valid peer name with getpeername(). If it has a valid peer name then it assumes nowait mode, otherwise it assumes wait mode. But this is unreliable, because if it is run in nowait mode and a client connects and disconnects very quickly then the socket will no longer have a valid peer name when Xvnc checks and it will mistakenly use wait mode. The 100% CPU results from repeatedly trying to call accept() on the socket in the select loop.
My solution is to instead detect wait vs. nowait via getsockopt(..., SOL_SOCKET, SO_ACCEPTCONN, ...), which works reliably in both modes. ** Patch added: "vnc4server-fix-100-percent-cpu-hang-in-inetd-mode.debdiff" https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/819473/+attachment/2345917/+files/vnc4server-fix-100-percent-cpu-hang-in-inetd-mode.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/819473 Title: Xvnc consumes 100% CPU usage after client disconnects To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/819473/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
