Ok, I have just taken another look into vncserver and checked it. In fact,
IceWM is being started by /etc/X11/xinit/xinitrc, since I wanted it to be
the global default window manager and I didn't want to configure this user
by user (I have plenty of them). xinitrc is already being invoked in
background (with &). I have tried to add nohup to its invokation, but it
didn't work out, I have the same behavior. I really don't get it...

Cheers,

Rafael Guimarães

2009/10/20 DRC <[email protected]>

> Xvnc doesn't actually create the WM process.  Both processes are created
> by the vncserver Perl script.  The vncserver script executes
> ~/.vnc/xstartup.turbovnc, which is presumably where IceWM is being
> called.  I would try either backgrounding IceWM in the xstartup.turbovnc
> file ('icewm &' or whatnot) and/or invoking IceWM with nohup in the same
> file.
>
> Another data point would be whether this occurs with any process started
> in xstartup.turbovnc or whether it just occurs with IceWM.
>
> DRC
>
> Rafael Guimaraes wrote:
> > Hi,
> >
> > First of all, thanks a lot for your comments. After going through lots
> > of logs and debugging, I have realized that my VNC sessions are
> > terminated due to an apache restart. Every sunday, the apache logs are
> > rotated (a cron job calls logrotate) and httpd is killed -HUP. And
> > exactly at this moment, every running IceWM session is terminated. I
> > still didn't find out why this happens, but this is the reason.
> >
> > Although VNC sessions are created through an PHP script, if I run "ps
> > -ef" I see that their parent pid is 1, so they should not be attached to
> > the httpd process (at least in theory). However, if I create one VNC
> > session through PHP and the other manually (running the same command in
> > the shell session), the PHP started session is terminated whenever I
> > "kill -HUP httpd" while the manually started session keeps running. The
> > most funny thing is that the PHP process calls the vncserver script,
> > which calls Xvnc. And, as far as I understood, XVnc is the one that
> > creates the window manager processes (in my case, IceWM). But when I
> > "kill -HUP httpd", Xvnc processes keep running, while IceWM terminates.
> > I have also checked the files that these processes have opened and there
> > are no common files... So, I am still a bit lost. I have tried to call
> > vncserver with "nohup vncserver" from the PHP script, but the same
> > happens...
> >
> > Any suggestions?
> >
> > Best regards,
> >
> > Rafael Guimarães
> >
> >
> > 2009/10/19 Rafael Guimaraes <[email protected] <mailto:[email protected]>>
> >
> >     I am sending the log below. It seems that at the exactly same time I
> >     had a few other sessions with the same problem (window manager was
> >     terminated). I have monitored the icewm process for this session and
> >     I have noticed that it terminated on 11/10/09 (dd/mm/yy) at
> >     04:02:04. There are other sessions that were also active at this
> >     time and had the same problem simultaneously (X connection to :16.0
> >     broken (explicit kill or server shutdown)). October 11st was sunday
> >     and I am pretty sure that nobody tried to connect to any session (or
> >     even to the server through ssh) at 4:02am during a sunday :) Any
> ideas?
> >
> >     Best regards,
> >
> >     Rafael Guimaraes
> >
> >
> >     05/10/09 16:14:34 Xvnc version turbo0.6
> >     05/10/09 16:14:34 Copyright (C) 2009 D. R. Commander
> >     05/10/09 16:14:34 Copyright (C) 2004-2008 Sun Microsystems, Inc.
> >     05/10/09 16:14:34 Copyright (C) 2004 Landmark Graphics Corporation
> >     05/10/09 16:14:34 Copyright (C) 2000-2009 TightVNC Group
> >     05/10/09 16:14:34 Copyright (C) 1999 AT&T Laboratories Cambridge
> >     05/10/09 16:14:34 All Rights Reserved.
> >     05/10/09 16:14:34 See http://www.virtualgl.org for more information
> >     05/10/09 16:14:34 Desktop name 'X' (juparana:16)
> >     05/10/09 16:14:34 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t,
> 3.8t
> >     05/10/09 16:14:34 Listening for VNC connections on TCP port 5916
> >     05/10/09 16:14:34 Listening for HTTP connections on TCP port 5816
> >     05/10/09 16:14:34   URL http://juparana:5816
> >     icewm-session: using /u/uqp6/.icewm for private configuration files
> >     IceWM: using /u/uqp6/.icewm for private configuration files
> >     icewmbg: using /u/uqp6/.icewm for private configuration files
> >     icewmtray: using /u/uqp6/.icewm for private configuration files
> >     05/10/09 16:14:39 httpd: get 'VncViewer.jar' for 10.23.201.56
> >     05/10/09 16:14:39 httpd: get 'VncViewer.jar' for 10.23.201.56
> >     05/10/09 16:14:39 httpd: get 'VncViewer.jar' for 10.23.201.56
> >
> >     05/10/09 16:14:39 Got connection from client 10.23.201.56
> >     05/10/09 16:14:39 Using protocol version 3.8
> >     05/10/09 16:14:39 Enabling TightVNC protocol extensions
> >     05/10/09 16:14:41 Full-control authentication passed by 10.23.201.56
> >     05/10/09 16:14:41 Using tight encoding for client 10.23.201.56
> >     05/10/09 16:14:41 rfbProcessClientNormalMessage: ignoring unknown
> >     encoding 16
> >     05/10/09 16:14:41 Using compression level 0 for client 10.23.201.56
> >     05/10/09 16:14:41 Using JPEG subsampling 0, Q100 for client
> 10.23.201.56
> >     05/10/09 16:14:41 Using image quality level 95 for client
> 10.23.201.56
> >     05/10/09 16:14:41 Using JPEG subsampling 0 for client 10.23.201.56
> >     05/10/09 16:14:41 Enabling X-style cursor updates for client
> >     10.23.201.56
> >     05/10/09 16:14:41 Enabling cursor position updates for client
> >     10.23.201.56
> >     05/10/09 16:14:41 Enabling LastRect protocol extension for client
> >     10.23.201.56
> >     05/10/09 16:14:41 rfbProcessClientNormalMessage: ignoring unknown
> >     encoding -223
> >     05/10/09 16:14:41 Pixel format for client 10.23.201.56
> >     <http://10.23.201.56>:
> >     05/10/09 16:14:41   32 bpp, depth 24, little endian
> >     05/10/09 16:14:41   true colour: max r 255 g 255 b 255, shift r 16 g
> >     8 b 0
> >     05/10/09 16:14:41   no translation needed
> >     05/10/09 16:14:50 Client 10.23.201.56 gone
> >     05/10/09 16:14:50 Statistics:
> >     05/10/09 16:14:50   key events received 0, pointer events 198
> >     05/10/09 16:14:50   framebuffer updates 26, rectangles 123, bytes
> 396818
> >     05/10/09 16:14:50     LastRect markers 6, bytes 72
> >     05/10/09 16:14:50     cursor shape updates 1, bytes 82
> >     05/10/09 16:14:50     cursor position updates 1, bytes 12
> >     05/10/09 16:14:50     tight rectangles 115, bytes 396652
> >     05/10/09 16:14:50   raw bytes equivalent 7306024, compression ratio
> >     18.419229
> >
> >     05/10/09 16:17:54 Got connection from client 10.23.201.56
> >     05/10/09 16:17:54 Using protocol version 3.8
> >     05/10/09 16:17:54 Enabling TightVNC protocol extensions
> >     05/10/09 16:17:59 Full-control authentication passed by 10.23.201.56
> >     05/10/09 16:17:59 Using tight encoding for client 10.23.201.56
> >     05/10/09 16:17:59 rfbProcessClientNormalMessage: ignoring unknown
> >     encoding 16
> >     05/10/09 16:17:59 Using compression level 0 for client 10.23.201.56
> >     05/10/09 16:17:59 Using JPEG subsampling 0, Q100 for client
> 10.23.201.56
> >     05/10/09 16:17:59 Using image quality level 95 for client
> 10.23.201.56
> >     05/10/09 16:17:59 Using JPEG subsampling 0 for client 10.23.201.56
> >     05/10/09 16:17:59 Enabling X-style cursor updates for client
> >     10.23.201.56
> >     05/10/09 16:17:59 Enabling cursor position updates for client
> >     10.23.201.56
> >     05/10/09 16:17:59 Enabling LastRect protocol extension for client
> >     10.23.201.56
> >     05/10/09 16:17:59 rfbProcessClientNormalMessage: ignoring unknown
> >     encoding -223
> >     05/10/09 16:17:59 Pixel format for client 10.23.201.56
> >     <http://10.23.201.56>:
> >     05/10/09 16:17:59   32 bpp, depth 24, little endian
> >     05/10/09 16:17:59   true colour: max r 255 g 255 b 255, shift r 16 g
> >     8 b 0
> >     05/10/09 16:17:59   no translation needed
> >     05/10/09 16:18:02 Client 10.23.201.56 gone
> >     05/10/09 16:18:02 Statistics:
> >     05/10/09 16:18:02   key events received 0, pointer events 32
> >     05/10/09 16:18:02   framebuffer updates 3, rectangles 38, bytes
> 240836
> >     05/10/09 16:18:02     LastRect markers 1, bytes 12
> >     05/10/09 16:18:02     cursor shape updates 1, bytes 82
> >     05/10/09 16:18:02     cursor position updates 1, bytes 12
> >     05/10/09 16:18:02     tight rectangles 35, bytes 240730
> >     05/10/09 16:18:02   raw bytes equivalent 5886436, compression ratio
> >     24.452440
> >     07/10/09 09:03:39 httpd: get 'VncViewer.jar' for 10.23.207.73
> >     07/10/09 09:03:39 httpd: get 'VncViewer.jar' for 10.23.207.73
> >     07/10/09 09:03:40 httpd: get 'VncViewer.jar' for 10.23.207.73
> >
> >     07/10/09 09:03:40 Got connection from client 10.23.207.73
> >     07/10/09 09:03:40 Using protocol version 3.8
> >     07/10/09 09:03:40 Enabling TightVNC protocol extensions
> >     07/10/09 09:03:47 rfbVncAuthProcessResponse: authentication failed
> >     from 10.23.207.73
> >     07/10/09 09:03:47 Client 10.23.207.73 gone
> >     07/10/09 09:03:47 Statistics:
> >     07/10/09 09:03:47   framebuffer updates 0, rectangles 0, bytes 0
> >
> >     07/10/09 09:03:49 Got connection from client 10.23.207.73
> >     07/10/09 09:03:49 Using protocol version 3.8
> >     07/10/09 09:03:49 Enabling TightVNC protocol extensions
> >     07/10/09 09:03:53 Client 10.23.207.73 gone
> >     07/10/09 09:03:53 Statistics:
> >     07/10/09 09:03:53   framebuffer updates 0, rectangles 0, bytes 0
> >     X connection to :16.0 broken (explicit kill or server shutdown).
> >     X connection to :16.0 broken (explicit kill or server shutdown).
> >     X connection to :16.0 broken (explicit kill or server shutdown).
> >     11/10/09 04:02:04 Xvnc version turbo0.6
> >     11/10/09 04:02:05 Copyright (C) 2009 D. R. Commander
> >     11/10/09 04:02:05 Copyright (C) 2004-2008 Sun Microsystems, Inc.
> >     11/10/09 04:02:05 Copyright (C) 2004 Landmark Graphics Corporation
> >     11/10/09 04:02:05 Copyright (C) 2000-2009 TightVNC Group
> >     11/10/09 04:02:05 Copyright (C) 1999 AT&T Laboratories Cambridge
> >     11/10/09 04:02:05 All Rights Reserved.
> >     11/10/09 04:02:05 See http://www.virtualgl.org for more information
> >     11/10/09 04:02:05 Desktop name 'X' (juparana:16)
> >     11/10/09 04:02:05 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t,
> 3.8t
> >     icewmbg: using /u/uqp6/.icewm for private configuration files
> >     18/10/09 04:02:04 Xvnc version turbo0.6
> >     18/10/09 04:02:04 Copyright (C) 2009 D. R. Commander
> >     18/10/09 04:02:04 Copyright (C) 2004-2008 Sun Microsystems, Inc.
> >     18/10/09 04:02:04 Copyright (C) 2004 Landmark Graphics Corporation
> >     18/10/09 04:02:04 Copyright (C) 2000-2009 TightVNC Group
> >     18/10/09 04:02:04 Copyright (C) 1999 AT&T Laboratories Cambridge
> >     18/10/09 04:02:04 All Rights Reserved.
> >     18/10/09 04:02:04 See http://www.virtualgl.org for more information
> >     18/10/09 04:02:04 Desktop name 'X' (juparana:16)
> >     18/10/09 04:02:04 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t,
> 3.8t
> >
> >
> >     2009/10/19 DRC <[email protected]
> >     <mailto:[email protected]>>
> >
> >         As far as I know, there isn't a timeout in TurboVNC, and it's
> >         doubtful
> >         that this is due to a WM timeout, since you tried it with
> >         multiple WM's.
> >          Perhaps there is some timing variable that is hitting a 32-bit
> >         limit or
> >         something like that and then, for whatever reason, disallowing
> any
> >         further connections from X clients.
> >
> >         Can you send me the VNC log (~/.vnc/`hostname`-:n.log, where n
> >         is the
> >         display number) from when this occurs?  There may be something
> >         in there
> >         that indicates what is happening.
> >
> >         Rafael Guimaraes wrote:
> >         > Hi,
> >         >
> >         > I have built a visualization server using TurboVNC v.0.6 and
> >         VirtualGL
> >         > v. 2.1.1. In this server, I am able to launch several remote
> >         sessions
> >         > using TurboVNC. Each of the these sessions uses a different
> >         display
> >         > number (:1, :2, :3 ...). However, I am facing some problems
> >         with session
> >         > timeout. If I create a TurboVNC session and do not use it for
> >         about 4
> >         > days, the window manager of this session (i.e. its processes)
> is
> >         > terminated. In this case, after about 4 days, if I connect to
> >         the VNC
> >         > session, I can only see the X cursor on a gray background (no
> >         window
> >         > manager, just Xvnc).
> >         >
> >         > I am currently using IceWM, but I have also tried with JWM and
> >         I had the
> >         > same problem. Does anybody know what might be the problem? Is
> >         there some
> >         > kind of timeout in TurboVNC that may be producing the behavior?
> >         >
> >         > Just for your additional information, I connect to the server
> >         using the
> >         > TurboVNC java applet cliente (http://server:590x).
> >         >
> >         > Thanks in advance!
> >         >
> >         > Best regards,
> >         >
> >         > Rafael Guimarães
> >         >
> >         >
> >         >
> >
> ------------------------------------------------------------------------
> >         >
> >         >
> >
> ------------------------------------------------------------------------------
> >         > Come build with us! The BlackBerry(R) Developer Conference in
> >         SF, CA
> >         > is the only developer event you need to attend this year.
> >         Jumpstart your
> >         > developing skills, take BlackBerry mobile applications to
> >         market and stay
> >         > ahead of the curve. Join us from November 9 - 12, 2009.
> >         Register now!
> >         > http://p.sf.net/sfu/devconference
> >         >
> >         >
> >         >
> >
> ------------------------------------------------------------------------
> >         >
> >         > _______________________________________________
> >         > VirtualGL-Users mailing list
> >         > [email protected]
> >         <mailto:[email protected]>
> >         > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
> >
> ------------------------------------------------------------------------------
> >         Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> >         is the only developer event you need to attend this year.
> >         Jumpstart your
> >         developing skills, take BlackBerry mobile applications to market
> >         and stay
> >         ahead of the curve. Join us from November 9 - 12, 2009. Register
> >         now!
> >         http://p.sf.net/sfu/devconference
> >         _______________________________________________
> >         VirtualGL-Users mailing list
> >         [email protected]
> >         <mailto:[email protected]>
> >         https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > VirtualGL-Users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> VirtualGL-Users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
VirtualGL-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Reply via email to