XDMCP problem

Bug #24271 reported by Zoltan Peczoli
14
Affects Status Importance Assigned to Milestone
kdebase (Ubuntu)
Fix Released
Medium
Jonathan Riddell

Bug Description

Kdm prints the following error message in the daemon.log whenever I want to
connect to my box from a remote computer via XDMCP:

Oct 19 16:42:04 hostname kdm[23336]: Unknown session exit code 0 (sig 11) from
manager process

then the remote client disconnects, so KDM is unusable in both query and
indirect mode.

See also bug report #18000 with the same error message

Revision history for this message
kgadeyne (klaas-gadeyne) wrote :
Download full text (4.0 KiB)

(In reply to comment #0)
> Kdm prints the following error message in the daemon.log whenever I want to
> connect to my box from a remote computer via XDMCP:
>
> Oct 19 16:42:04 hostname kdm[23336]: Unknown session exit code 0 (sig 11) from
> manager process
>
> then the remote client disconnects, so KDM is unusable in both query and
> indirect mode.
>
> See also bug report #18000 with the same error message

Confirmed here.
Some more info: As stated in #18000, xdmcp works fine using gdm. The problem
started when upgrading from hoary to breezy.
When running kdm with the -debug 6761 option, the following info gets printed in syslog
Oct 21 11:43:33 localhost kdm[18779]: select returns 1
Oct 21 11:43:33 localhost kdm[18779]: ProcessRequestSocket
Oct 21 11:43:33 localhost kdm[18779]: header: 1 2 1
Oct 21 11:43:33 localhost kdm[18779]: <query> respond 1
Oct 21 11:43:33 localhost kdm[18779]: ConvertAddr returning 0 for family 10
Oct 21 11:43:33 localhost kdm[18779]: all_query_respond: conntype=0, addr=4: c0
a8 f6 48
Oct 21 11:43:33 localhost kdm[18779]: ScanAccessDatabase
Oct 21 11:43:33 localhost kdm[18779]: caught signal 17
Oct 21 11:43:33 localhost kdm[18779]: send <willing> (null) 1 user, load: 0.11,
0.05, 0.01
Oct 21 11:43:33 localhost kdm[18779]: select returns 1
Oct 21 11:43:34 localhost kdm[18779]: select returns 1
Oct 21 11:43:34 localhost kdm[18779]: ProcessRequestSocket
Oct 21 11:43:34 localhost kdm[18779]: header: 1 7 81
Oct 21 11:43:34 localhost kdm[18779]: <request> respond 81
Oct 21 11:43:34 localhost kdm[18779]: FindProtoDisplay
Oct 21 11:43:34 localhost kdm[18779]: NewProtoDisplay
Oct 21 11:43:34 localhost kdm[18779]: NewProtoDisplay 0x08066e10
Oct 21 11:43:34 localhost kdm[18779]: got 0x08066748 (18 MIT-MAGIC-COOKIE-1)
Oct 21 11:43:34 localhost kdm[18779]: <accept> session ID 230048001
Oct 21 11:43:34 localhost kdm[18779]: select returns 1
Oct 21 11:43:34 localhost kdm[18779]: ProcessRequestSocket
Oct 21 11:43:34 localhost kdm[18779]: header: 1 10 23
Oct 21 11:43:34 localhost kdm[18779]: <manage> 23
Oct 21 11:43:34 localhost kdm[18779]: FindProtoDisplay
Oct 21 11:43:34 localhost kdm[18779]: <manage> session ID 230048001, pdpy 0x08066e10
Oct 21 11:43:34 localhost kdm[18779]: computed display name:
LT00101.labo01.fmtc.be:3
Oct 21 11:43:34 localhost kdm[18779]: created new display LT00101.labo01.fmtc.be:3
Oct 21 11:43:34 localhost kdm[18779]: ConvertAddr returning 0 for family 10
Oct 21 11:43:34 localhost kdm[18779]: starting display
LT00101.labo01.fmtc.be:3,MIT-unspecified
Oct 21 11:43:34 localhost kdm[18779]: StartDisplay LT00101.labo01.fmtc.be:3, try 1
Oct 21 11:43:34 localhost kdm[18779]: file:
/var/run/xauth/ALT00101.labo01.fmtc.be:3-EUWtdg auth: 0x08066f18
Oct 21 11:43:34 localhost kdm[18779]: forking session
Oct 21 11:43:34 localhost kdm: LT00101.labo01.fmtc.be:3[18811]: before
XOpenDisplay(LT00101.labo01.fmtc.be:3)
Oct 21 11:43:34 localhost kdm[18779]: forked session, pid 18811
Oct 21 11:43:34 localhost kdm: LT00101.labo01.fmtc.be:3[18811]: after
XOpenDisplay(LT00101.labo01.fmtc.be:3)
Oct 21 11:43:34 localhost kdm: LT00101.labo01.fmtc.be:3[18811]: got remote
address LT00101.labo01.fmtc.be:3 16
Oct 21 11:43:34 localhost k...

Read more...

Revision history for this message
Jason Straight (jason-jeetkunedomaster) wrote :

I confirm this. Now if only had I found this bug report before I spent all day thinking it was just me doing something wrong, as this is my first time setting up xdmcp on anything. :(

Revision history for this message
Jim McQuillan (jam-mcquil) wrote :

This bug is making it impossible to install LTSP-4.2 on Kubuntu, as LTSP requires XDMCP.

I can replace kdm with gdm, and it should work, but I really think kdm needs to be fixed.

For what it's worth, kdm on Fedora fc5 is version 3.5.1, and it works fine with xdmcp.

Revision history for this message
Elijah Lofgren (elijahlofgren) wrote :

I remember running into this bug and it went away after upgrading to KDE 3.5

KDE 3.5.2 is available for Breezy: http://kubuntu.org/announcements/kde-352.php

Also, if you upgrade to Dapper it has KDE 3.5.2.

Revision history for this message
Rich Johnson (nixternal) wrote :

Is this bug still present in the latest Dapper packages?

If it is not, or if someone knows that this bug has been fixed by a subsequent upload, please let us know so we can close this. The last activity on this bug was over a few months ago.

Thank you for reporting this bug.

Revision history for this message
Elijah Lofgren (elijahlofgren) wrote :

I think this bug can be closed. I'm running Kubuntu 6.06 and XDMCP works fine with KDM. I think this bug only existed in the KDE 3.4.x versions, all 3.5.x KDE versions should fix this problem.

Revision history for this message
Lothar Braun (typecast) wrote :

Closed since Elijah found that the bug disappeared and the original reporter did not respond. Thanks for reporting and please reopen the bug if you can still reproduce the bug.

Changed in kdebase:
status: Unconfirmed → Fix Committed
Changed in kdebase:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.