Public bug reported:
Binary package hint: gdm
The logic in gdm-xdmcp-manager.c that calls the
gdm_xdmcp_recount_sessions() function seems to be broken. Here we do
have a system running as a terminal server with SunRays connected to an
intrepid system. We noticed that XDMCP sessions are declined if more
than MaxSessions Sunrays are connected to the server. However, SunRay
connections are not using XDMCP but are local displays and such
shouldn't be counted as such.
So here we receive the following error if we are trying to open
additional XDMCP sessions on this server with more than MaxSessions
Sunrays or local displays connected:
-- cut here --
Fatal server error:
XDMCP fatal error: Session declined Maximum number of open sessions reached
-- cut here --
And the debug output of gdm also states that the number of XDMCP
sessions are exhausted despite the fact that no XDMCP sessions are open.
After a short review of the gdm sources we found the following lines in
the gdm-xdmcp-manager.c sources to be the reason for the error:
--- cut here ---
if (g_slist_length (gdm_daemon_config_get_display_list()) <
manager->priv->num_sessions ) {
gdm_xdmcp_recount_sessions (manager);
}
--- cut here ---
The problem with these lines is that recount_sessions() is only called
when the number of all sessions (even sessions not including XDMCP
sessions) is smaller than the current number of XDMCP sessions. But this
is incorrect because SunRay sessions are not using XDMCP. Also this is
reproducable for example if you have multiple local gdm displays open
which exhaust the number of MaxSessions.
To reproduce the bug, just set MaxSessions to 2 and open two local gdm
displays not using XDMCP. You will notice that as soon as two local
displays are open you can not open any foreign XDMCP session.
The expected result would have been to have the "xdmcp/MaxSessions"
option to be completly independent from the total number of graphical
sessions.
In addition, please note that in the closed bug #152068 a fixed was
proposed for a similar problem. But since then the above if logical
creeped in and thus is causing the described problems. Also the old
bugreport at gnome (http://bugzilla.gnome.org/show_bug.cgi?id=478441)
explains a fix where the if logical is not present.
As for an intermediate fix we have recompiled gdm ourself and commented
out the if() logical so that recount_sessions() is called at every
session request. This immediately fixed our problems with declined XDMCP
sessions.
Please note that we are running Ubuntu 8.10 (intrepid) and have verified
that bug with gdm 2.20.8 as well as with the latest 2.20.10 version
supplied in jaunty.
** Affects: gdm (Ubuntu)
Importance: Undecided
Status: New
--
recounting logic for num_sessions in MaxSessions check of XDMCP broken
https://bugs.launchpad.net/bugs/345797
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
