Since Xvnc is single-threaded, if you are able to telnet in on 59xx, that means that the server is not locked up. That leaves the following as possibilities in my mind:
-- Perhaps this is due to a problem in the X11 client library. If so, then there's probably nothing I can do about it. Try updating your system to the latest O/S patches? -- Double-check permissions on /tmp, /tmp/.X11-unix, etc. They should be writable by whoever used is launching the VNC server. -- If all else fails, then perhaps you can work around it by disabling local X11 communications. You do this by starting Xvnc with '-nolisten local', which forces it to listen for X11 traffic on a TCP socket rather than a local socket, so it will not use /tmp/.X11-unix/X* in that case. Several things that I still don't understand about this situation: -- If you mentioned what O/S these machines are running, I missed it, so please provide that information. If it's an O/S I haven't tested, then I'm happy to try reproducing it on my end, but you implied that there was nothing different about the machines that were experiencing the bug vs. the machines that aren't (?) -- When the X server "locks up", does it remain locked? That is, do repeated attempts to run vncpasswd fail in the same way? -- Have you tried to assign a regular VNC password to the session? That would give you a way to log in and verify whether it is still properly accepting client connections once vncpasswd starts failing. I'm not saying that there's no possibility of a bug in TurboVNC, but we do have thousands of seats worldwide that are using portals built around the OTP functionality. These portals are dynamically generating OTPs every time a user launches or reconnects to a session, so it seems to me that if this was a bug in TurboVNC, someone else would have stumbled upon it by now. On 10/24/13 9:26 AM, Rafael Guimaraes wrote: > Hi DRC, > > Just some last information... I have tried to telnet Xvnc (in ports 5813 > and 5913, since I using display 13) in order to see if the Xvnc process > is completely locked or not and it seems to be responding to my > connections correclty. > > I have opened a telnet to port 5813, sent a "GET /VncViewer.jar" and was > able to download the applet. Then I opened a telnet to port 5913, > received "RFB 003.008", send "RFB 003.003" and got some binary info I > was not able to figure out... But it seems to be responding correctly, > it is not completely locked. I don't know what further tests should I do > for finding out what's happening. Since it has already happened twice, > in two different machines, I would like to know as much as I possible in > order to avoid it from happening again in the future... > > Cheers, > > Rafael > > > 2013/10/24 Rafael Guimaraes <rgu...@gmail.com <mailto:rgu...@gmail.com>> > > Hi DRC, > > I overcame my laziness and launched vncpasswd with gdb. The result > was pretty much the same of what strace and printfs have shown. The > problem really seems to be in the communication with the Xvnc server... > > Cheers, > > Rafael > > > > Reading symbols from /opt/TurboVNC/bin/vncpasswd...Reading symbols > from /usr/lib/debug/opt/TurboVNC/bin/vncpasswd.debug...done. > done. > (gdb) r -o -display :13 > Starting program: /opt/TurboVNC/bin/vncpasswd -o -display :13 > > Program received signal SIGINT, Interrupt. > 0x000000371f6cc30f in poll () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000371f6cc30f in poll () from /lib64/libc.so.6 > #1 0x000000372124a9f0 in ?? () from /usr/lib64/libX11.so.6 > #2 0x000000372124ae19 in _XRead () from /usr/lib64/libX11.so.6 > #3 0x00000037212378c9 in XOpenDisplay () from /usr/lib64/libX11.so.6 > #4 0x000000000040187c in DoOTP () at vncpasswd.c:81 > #5 0x0000000000402187 in main (argc=4, argv=0x7fffffffe748) at > vncpasswd.c:293 > (gdb) > > > > 2013/10/24 Rafael Guimaraes <rgu...@gmail.com <mailto:rgu...@gmail.com>> > > Hi DRC, > > I have followed the best debugging practice there is (don't > worry, I'm being ironic :)), putting printfs around the possible > problem and I figured out that the vncpasswd hangs when calling > XOpenDisplay. When executing the code below, it prints "Opening > display :13" and nothing else. If I run it with strace, I get > the trace below. > > I didn't do the gdb test just because I am not very familiar > with doing it by gdb (I've already done it before, but there has > been centuries). If the following information is not enough and > gdb would help, I am sure I can handle it, no problem. I am just > trying to make thing easier for me! A little bit egocentric, I > know, but I just can't help it... :) > > If you check the strace output, it hangs on the last line, when > I seems to be trying to communicate through a socket > "/tmp/.X11-unix/X13". I imagine it is trying to reach Xvnc on > display 13 and it is getting no response, so it keeps waiting > forever... Am I right? What should I do if this is the case? > > Cheers, > > Rafael > > VNCPASSWD CODE WITH PRINTFS: > > int DoOTP() > { > unsigned int full; > unsigned int view = 0; > Display* dpy; > Atom prop; > int len; > char buf[MAXPWLEN + 1]; > char bytes[MAXPWLEN * 2]; > #ifdef UseDevUrandom > int fd; > #endif > > *printf("Opening display %s\n",displayname);* > if ((dpy = XOpenDisplay(displayname)) == NULL) { > fprintf(stderr, "unable to open display \"%s\"\n", > XDisplayName(displayname)); > return(1); > } > *printf("Display opened\n");* > > > STRACE: > > write(1, "Opening display :13\n", 20Opening display :13 > ) = 20 > brk(0) = 0x59f3000 > brk(0x5a14000) = 0x5a14000 > uname({sys="Linux", node="server03", ...}) = 0 > socket(PF_FILE, SOCK_STREAM, 0) = 3 > uname({sys="Linux", node="server03", ...}) = 0 > uname({sys="Linux", node="server03", ...}) = 0 > connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X13"...}, > 20) = 0 > uname({sys="Linux", node="server03", ...}) = 0 > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > access("/u/cnhu/.Xauthority", R_OK) = 0 > open("/u/cnhu/.Xauthority", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0600, st_size=13139, ...}) = 0 > mmap(NULL, 32768, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b34aa97f000 > read(4, "\1\0\0\10mi080113\0\00210\0\22MIT-MAGIC-COOK"..., > 32768) = 13139 > read(4, "", 32768) = 0 > close(4) = 0 > munmap(0x2b34aa97f000, 32768) = 0 > writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, > {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, > {"e\30\226A>\316@\17Y8\365+V\21\365\f", 16}], 4) = 48 > fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) > fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > read(3, 0x7fff865304b0, 8) = -1 EAGAIN (Resource > temporarily unavailable) > poll([{fd=3, events=POLLIN}], 1, -1 <unfinished ...> > > > > > 2013/10/24 DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> > > Can you figure out where in the vncpasswd code it's locking > up? That > would help diagnose the issue. If you're using an RPM-based > system, you > can install the turbovnc-debuginfo RPM and get a stack trace > from gdb > when it locks up. Otherwise, you'll have to build vncpasswd > from > source, but it's straightforward. > > This is a complete shot in the dark, but I'm wondering if > maybe the > /dev/urandom device is somehow giving you problems on some > of your > machines. vncpasswd will read from /dev/urandom when it > generates an > OTP. If that is the problem, then adding > > #undef UseDevUrandom > > to the top of vncpasswd.c should temporarily work around it, > and it > would be easy to add a more permanent workaround (a command > line switch > that avoids using /dev/urandom.) > > > On 10/23/13 1:36 PM, Rafael Guimaraes wrote: > > Hi, > > > > I have created a VNC session and after using it for sometime, > it seems > > to be "locked". It is configured to use one-time-passwords and > I just > > can't generate a new otp for access the session, vncpasswd hangs > > indefinitely when trying to get a new password. > > > > The session was created by the following command line: > > /opt/TurboVNC/bin/Xvnc :13 -desktop X -httpd > > /opt/TurboVNC/bin/../vnc/classes -auth /u/cnhu/.Xauthority > > -dontdisconnect -geometry 3192x1046 -depth 24 -rfbwait 120000 > -otpauth > > -rfbport 5913 -fp > > > /usr/share/X11/fonts/misc,/usr/share/X11/fonts/75dpi,/usr/share/X11/fonts/100dpi,/usr/share/X11/fonts/Type1,/usr/share/fonts/default/Type1 > > -co /usr/share/X11/rgb -deferupdate 1 > > > > When trying to launch a "vncpasswd -otp -display :13", I get no > response > > and eventually I have to press Ctrl+C. I have runned the > vncpasswd > > command line with strace and it seems to hang while trying to > connect to > > Xvnc through the "/tmp/.X11-unix/X13" socket (not sure if I've > got it > > right). Below you may check the end of the strace (until it > hangs). > > > > What may the problem be? The same happened twice in two > different > > machines. I have several other VNC sessions where this does not > happen. > > Can I collect information from anywhere else that could help me > trying > > to figure out what happened? > > > > uname({sys="Linux", node="server03", ...}) = 0 > > socket(PF_FILE, SOCK_STREAM, 0) = 3 > > uname({sys="Linux", node="server03", ...}) = 0 > > uname({sys="Linux", node="server03", ...}) = 0 > > connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X13"...}, > 20) = 0 > > uname({sys="Linux", node="server03", ...}) = 0 > > fcntl(3, F_SETFD, FD_CLOEXEC) = 0 > > access("/u/cnhu/.Xauthority", R_OK) = 0 > > open("/u/cnhu/.Xauthority", O_RDONLY) = 4 > > fstat(4, {st_mode=S_IFREG|0600, st_size=13139, ...}) = 0 > > mmap(NULL, 32768, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, > > 0) = 0x2ab9583b5000 > > read(4, "\1\0\0\10mi080113\0\00210\0\22MIT-MAGIC-COOK"..., > 32768) = 13139 > > read(4, "", 32768) = 0 > > close(4) = 0 > > munmap(0x2ab9583b5000, 32768) = 0 > > writev(3, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, > {"MIT-MAGIC-COOKIE-1", > > 18}, {"\0\0", 2}, {"e\30\226A>\316@\17Y8\365+V\21\365\f", 16}], > 4) = 48 > > fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) > > fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > > read(3, 0x7fff0b98aab0, 8) = -1 EAGAIN (Resource > > temporarily unavailable) > > poll([{fd=3, events=POLLIN}], 1, -1 <unfinished ...> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application > performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. > Get the most from > the latest Intel processors and coprocessors. See abstracts > and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
