Date: Wed, 06 Feb 2002 05:40:53 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: questions@freebsd.org Subject: Re: VNC and KDM/KDE interaction Message-ID: <3C613265.E4878634@mindspring.com> References: <3C6122C2.A93A97B7@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... answering myself, and I've "Bcc:"'ed "bugs" ... ] Terry Lambert wrote: > Everything appears to work fine with this setup, except... > logouts from KDE take a very long time to take effect, > leaving the sreen at the KDE login. > > Would it be better to have the /etc/ttys version of KDM > also start the Xvnc server? > > It's not obvious to me, but it seems that the logout is > perhaps depending on the X server being stopped, therefore > killing off the clients, rather than the logout itself > doing the kill? > > Is this a known KDM/KDE problem with remote/non-standard > X servers? It's a FreeBSD problem. Adding: :1 local /usr/X11R6/bin/Xvnc :1 -desktop X -httpd /usr/X11R6/share/vnc/classes - auth /root/.Xauthority -geometry 1000x740 -depth 8 -rfbwait 120000 -rfbauth /roo t/.vnc/passwd -rfbport 5901 -dontdisconnect To /usr/X11R6/lib/X11/xdm/Xservers works around the problem. Apparently, this is yet another case of the FreeBSD group signal delivery semantics being correct per POSIX, but not working like 4.3BSD or System V systems used to work (e.g. revoking the tty before delivering the signal, so not all processes in the process group get the SIGHUP like they are supposed to get when the process group leader goes away). What happens is kwm exits, and then a SIGHUP is delivered to everything bu the X server, but the deliver fails because of the revocation semantics being non-standard. So the processes hang out until there's a timeout in kdm, and the session leader is reaped, causing kdm to reset the server, and the login pops back up. Making the X server itself a child of kdm makes it the group leader, which in turn ensures that the X server will get the SIGHUP. This causes it to reset, dumping all the clients on the floor, and you get the (expected) fast logout and the KDM login pops up in a reasonable period of time. This is a problem for xdm and kdm for all FreeBSD boxes, with KDE, using non-local X servers (I verified xdm with this). It is probably a problem with other window managers. So if you've noticed that FreeBSD doesn't restore the KDE session state properly, the reason is that the server is reset, instead of the processes attached to the server getting the HUP. You can repeat this by running kdm with no X servers, allowing XDMCP, and running a local X server in "-query", so there's no need for VNC in the equation at all. In any case, my workaround is working for me, so I'm (mostly) happy with it, since I never noticed the session save stuff not working on FreeBSD until I used an external X server not stated by the display manager program. FWIW, the way 4.3 and System V handled HUP was to deliver it to the session leader, then deliver it to the children, delaying the actual revocation of the tty until all group leaders had been signalled, with each process that loses its leader becoming a leader automatically. This could be done pretty easily, I think, by having a list of who has a terminal as controlling tty and is a group leader, and inheriting the controlling process, rather than revoking, and saving the revoke until the last close (the purpose of the revoke is to stop new opens, not invalidate old ones). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C613265.E4878634>