Bug 1337067
| Summary: | gdm xdmcp session dead | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Christoph <c.handel> |
| Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | Lucie Vařáková <lmanasko> |
| Priority: | high | ||
| Version: | 6.6 | CC: | afinkelsrc, andreas.in.hk+RHbugzilla, ayadav, diego.santacruz, masakazu.mokuno, mboisver, paddy, rstrode, tpelka |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | gdm-2.30.4-66.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: In correct state handling in XDMCP codepaths
Consequence: XDMCP sessions would die after 3 minutes
Fix: A call to perform the correction state transition at the appropiate time was added
Result: XDMCP sessions last until the user logs out.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-21 11:37:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Christoph
2016-05-18 08:12:08 UTC
Just a 'me too' on this. Seeing the same behaviour. Have copied in a tcpdump below of the packets which are sent just before the client is kicked off if it sheds any light.
17:51:21.001274 IP 10.11.113.75.37041 > 10.11.113.65.177: UDP, length 12
0x0000: 4500 0028 0000 4000 4011 4a74 86e2 714b E..(..@.@.Jt..qK
0x0010: 86e2 7141 90b1 00b1 0014 faa9 0001 000d ..qA............
0x0020: 0006 0001 26d4 5c7f 0000 0000 0000 ....&.\.......
17:51:21.006042 IP 10.11.113.65.177 > 10.11.113.75.37041: UDP, length 11
0x0000: 4500 0027 0000 4000 4011 4a75 86e2 7141 E..'..@.@.Ju..qA
0x0010: 86e2 714b 00b1 90b1 0013 f075 0001 000e ..qK.......u....
0x0020: 0005 0026 d45c 7f ...&.\.
17:51:21.006337 IP 10.11.113.75.37041 > 10.11.113.65.177: UDP, length 7
0x0000: 4500 0023 0000 4000 4011 4a79 86e2 714b E..#..@.@.Jy..qK
0x0010: 86e2 7141 90b1 00b1 000f 7e18 0001 0002 ..qA......~.....
0x0020: 0001 0000 0000 0000 0000 0000 0000 ..............
17:51:21.008476 IP 10.11.113.65.177 > 10.11.113.75.37041: UDP, length 74
0x0000: 4500 0066 0000 4000 4011 4a36 86e2 7141 E..f..@.@.J6..qA
0x0010: 86e2 714b 00b1 90b1 0052 f0b4 0001 0005 ..qK.....R......
0x0020: 0044 0000 0012 .... .... .... .... .... .D....xxxxxxxxxx
0x0030: .... .... .... .... 002c 4c69 6e75 7820 xxxxxxxx.,Linux.
0x0040: 322e 362e 3332 2d36 3432 2e65 6c36 2e78 2.6.32-642.el6.x
0x0050: 3836 5f36 3420 2853 6572 7665 7220 6973 86_64.(Server.is
0x0060: 2062 7573 7929 .busy)
17:51:21.019500 IP 10.11.113.75.37041 > 10.11.113.65.177: UDP, length 7
0x0000: 4500 0023 0000 4000 4011 4a79 86e2 714b E..#..@.@.Jy..qK
0x0010: 86e2 7141 90b1 00b1 000f 7e18 0001 0002 ..qA......~.....
0x0020: 0001 0000 0000 0000 0000 0000 0000 ..............
17:51:21.021181 IP 10.11.113.65.177 > 10.11.113.75.37041: UDP, length 74
0x0000: 4500 0066 0000 4000 4011 4a36 86e2 7141 E..f..@.@.J6..qA
0x0010: 86e2 714b 00b1 90b1 0052 f0b4 0001 0005 ..qK.....R......
0x0020: 0044 0000 0012 .... .... .... .... .... .D..............
0x0030: .... .... .... .... 002c 4c69 6e75 7820 xxxxxxxx.,Linux.
0x0040: 322e 362e 3332 2d36 3432 2e65 6c36 2e78 2.6.32-642.el6.x
0x0050: 3836 5f36 3420 2853 6572 7665 7220 6973 86_64.(Server.is
0x0060: 2062 7573 7929 .busy)
17:51:21.223236 IP 10.11.113.75.37041 > 10.11.113.65.177: UDP, length 117
0x0000: 4500 0091 0000 4000 4011 4a0b 86e2 714b E.....@.@.J...qK
0x0010: 86e2 7141 90b1 00b1 007d aa05 0001 0007 ..qA.....}......
0x0020: 006f 0001 0300 0000 0600 0603 0004 86e2 .o..............
0x0030: 714b 0010 2001 0770 0010 0500 021d 09ff qK.....p........
0x0040: fe0d 96dc 0010 fe80 0000 0000 0000 021d ................
0x0050: 09ff fe0d 96dc 0000 0000 0300 124d 4954 .............MIT
0x0060: 2d4d 4147 4943 2d43 4f4f 4b49 452d 3100 -MAGIC-COOKIE-1.
0x0070: 1358 444d 2d41 5554 484f 5249 5a41 5449 .XDM-AUTHORIZATI
0x0080: 4f4e 2d31 0009 5355 4e2d 4445 532d 3100 ON-1..SUN-DES-1.
0x0090: 00 .
17:51:21.231932 IP 10.11.113.65.177 > 10.11.113.75.37041: UDP, length 52
0x0000: 4500 0050 0000 4000 4011 4a4c 86e2 7141 E..P..@.@.JL..qA
0x0010: 86e2 714b 00b1 90b1 003c f09e 0001 0008 ..qK.....<......
0x0020: 002e 26d4 5c83 0000 0000 0012 4d49 542d ..&.\.......MIT-
0x0030: 4d41 4749 432d 434f 4f4b 4945 2d31 0010 MAGIC-COOKIE-1..
0x0040: 90dc 5c8a 781f b6c0 3a5e 4ddd 5e66 8635 ..\.x...:^M.^f.5
17:51:21.232152 IP 10.11.113.75.37041 > 10.11.113.65.177: UDP, length 29
0x0000: 4500 0039 0000 4000 4011 4a63 86e2 714b E..9..@.@.Jc..qK
0x0010: 86e2 7141 90b1 00b1 0025 d3e1 0001 000a ..qA.....%......
0x0020: 0017 26d4 5c83 0001 000f 4d49 542d 756e ..&.\.....MIT-un
0x0030: 7370 6563 6966 6965 64 specified
I had same issue with Cygwin X server.
The reason for it was that gdm replied wrong state for XDMCP keepalive messages.
It always replied 'session not alive' in XDMCP alive messages.
Xservers like Cygwin's which use XDMCP keepalive will stop the session and restart if such replies are returned.
By looking at gdm's code, it did not seem that gdm set its internal connection state correctly, so it always decided the peer Xserver was unmanaged.
The following patch fixes the issue on my system, though I'm not pretty sure that it's right fix.
Hope this helps you.
diff -upr gdm-2.30.4.org/daemon/gdm-display.c gdm-2.30.4.fix/daemon/gdm-display.c
--- gdm-2.30.4.org/daemon/gdm-display.c 2010-06-17 01:32:38.000000000 +0900
+++ gdm-2.30.4.fix/daemon/gdm-display.c 2016-08-16 18:27:05.920590263 +0900
@@ -531,6 +531,8 @@ static void
_gdm_display_set_status (GdmDisplay *display,
int status)
{
+ g_debug ("GdmDisplay: status to %d", status);
+
if (status != display->priv->status) {
display->priv->status = status;
g_object_notify (G_OBJECT (display), "status");
@@ -619,6 +621,8 @@ gdm_display_real_manage (GdmDisplay *dis
g_assert (display->priv->slave_proxy != NULL);
+ _gdm_display_set_status (display, GDM_DISPLAY_MANAGED);
+
g_timer_start (display->priv->slave_timer);
gdm_slave_proxy_start (display->priv->slave_proxy);
Thank you, this issue should be resolved in the next synchronous update of Red Hat Enterprise Linux 6. While testing gdm-2.30.4-67.el6 I was able to have a x-session through Xephyr idling for about 15 minutes. Logged in, logged out, etc. According to the reproducer this should verify the fix. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0763.html |