On 05/12/09 15:24, Brian Cameron wrote: > I would be interested to hear if this problem is still happening on > a more recent build.
Certainly, as soon as one is available. Are you suggesting installing the latest SXCE instead? Is anyone still sending out the SXCE announcements? I haven't seen one since 04/06/09, so I have no idea what the most recent SXCE built might be. I suppose it must be almost at 116 by now, so maybe it is time to try gdm on SPARC again... > You say the GDM issue is general and happens on multiple distributions. No. GDM on Fedora C10 doesn't seem to support gdmsetup, let alone the gdm-chooser, any more, and this thread seems to confirm it: http://www.nabble.com/GDM-2.24.1-and-XDMCP-td21540035.html. But X :n -query <host> from Xorg will kill any :n session running under dtlogin (Xsun) on <host> from any distribution, at least with snv103, and this has been a problem at least since Solaris 10 when the querying host is not running dtlogin. Perhaps this is a difference between Xsun and Xorg, who knows? It could even be an endian problem, although I doubt it. In the next few weeks, I'll try OpenSolaris or a newer SXCE on SPARC and see if the problem occurs with that. > If this is the case, then I would recommend filing a bug at > http://bugzilla.gnome.org/. It is more likely to get fixed if the > issue is raised with the wider GDM community. Not sure why anyone in the broader community would be willing or able to fix this since they probably don't have dtremote hosts to test with. As previously noted, this has been filed as a bug at http://defect.opensolaris.org/bz/show_bug.cgi?id=8828. AFAIK this only impacts dtlogin users trying to remote host from OpenSolaris using the gdm chooser. As mentioned, a previous bug report against dtlogin to bugs.opensolaris.org simply vanished. Additional test information has been appended to bug #8828, which increasingly seems like a dtlogin vs. dtremote problem. > Ah yes, sorry. Looking at the GDM code, in the file > daemon/gdm-xdmcp-manager.c, it looks like the GDM daemon gets the > "clnt_dspnum" value from the XDMCP "REQUEST" packet. Right, so it seems the requestor has to pick a display number and send it to the daemon (dtremote in this case). The questions is - where does the requested display number come from? Unfortunately, the default seems to be zero and this kills the default console session. A trivial workaround is to change /etc/dt/config/Xservers to use a display number other than zero. Since the workaround is so trivial, and since the problem will go away with the demise of dtlogon/dtremote, it wouldn't surprise me if this bug were to be closed as wontfix, especially since one could argue that it really is a dtlogin bug. But this is more of a business decision for Sun about whether or not to ignore this or fix it and the number of users this affects is obviously rather small. But is is a bug, none the less, and it could probably be fixed in either gdm or dtlogin.
