RE: [Helix Beta] Re: gdm indirect XDMCP - anyone got working OK?

[Paul Jenner <p jenner eim surrey ac uk>]

	Thanks Martin.

> Indirect XDMCP doesn't work with GDM at all.  Never has.  It isn't
implemented.

	Indirect XDMCP does work in the way I meant but I phrased wrongly
what I was attempting.  What I mean is that all my X-terminals point
indirect XDM at a host running xdm which then points at a list of further
XDMCP hosts - one of which is a Red Hat box running Helix gdm.  Thus the gdm
does not provide the indirect XDMCP listener but it does provide a banner to
an X-terminal indirect query via the intermediate xdm host.

> Paul> Nov 16 21:46:42 molniya init: Id "x" respawning too fast:
> Paul> disabled for 5 minutes
> 
> So, it's dumping core or exiting due to a fatal error.  Check your
> logs for info.

	Sorry to be obvious about the symptom.  I have looked at the logs
for info (both gdm log files and syslog messages from gdm when running with
debug on) but could not find anything definite.  I'll look again when it
next happens.  Unfortunately I need the uptime on the box at the moment
which is supposed to be 24/7 so I cannot experiment with tracing or gdb'ing
the process.  I will when I get a chance.  Any idea where it would dump core
if spawned by init?

> Paul> My current fix is to boot runlevel 3, install gdm 2.0beta2 from
> Paul> a Red Hat rpm (this is the last known working version), go to
> Paul> runlevel 5 to provide indirect XDMCP and then upgrade to gdm
> Paul> 2.0beta4 when gdm is running.
> 
> Which means you'll keep running beta2...

	Doesn't appear that way Martin.  If I upgrade whilst the gdm process
is running, the original listener spawned by init is beta2 - thus it listens
OK to the indirect queries passed via the xdm host.  However when someone
actually requests a banner, the listener process spawns a child gdm process
to handle it.  As the gdm binary installed at this point is beta4, it spawns
a Helix beta4 gdm child session.  This is easy to see visibly because of
course the login banner looks completely different and offers different
options.  Does this make sense or am I reading something wrong here?

	On the subject of the Red Hat patches, they also have the problem.
Red Hat beta2 works but Red Hat beta4 (via their updated package) fails like
the Helix one.  The problem was definitely introduced between beta2 and
beta4.

	Thanks for all the help and if I narrow this down, I'll let you
kinow.

	Cheers,

	Paul

   -----------------------------------------------------------------------
        Paul S Jenner
        UNIX Systems Administrator
        Surrey Satellite Technology Limited

        E-mail:   P Jenner eim surrey ac uk

        UNSOLICITED COMMERCIAL E-MAIL IS NOT WELCOME AT THIS ADDRESS
   -----------------------------------------------------------------------

> -----Original Message-----
> From: Martin K. Petersen [mailto:mkp mkp net]
> Sent: 20 November 2000 15:13
> To: Paul Jenner
> Cc: 'beta helixcode com'; 'gdm sunsite auc dk'
> Subject: [Helix Beta] Re: gdm indirect XDMCP - anyone got working OK?
> 
> >>>>> "Paul" == Paul Jenner <p jenner eim surrey ac uk> writes:
> 
> Paul> I would be interested exchanging e-mail with anyone who has got
> Paul> indirect XDMCP working OK with Helix shipped gdm.  
> 
> Indirect XDMCP doesn't work with GDM at all.  Never has.  It isn't
> implemented.
>  
> Paul> Nov 16 21:46:42 molniya init: Id "x" respawning too fast:
> Paul> disabled for 5 minutes
> 
> So, it's dumping core or exiting due to a fatal error.  Check your
> logs for info.
> 
> Paul> My current fix is to boot runlevel 3, install gdm 2.0beta2 from
> Paul> a Red Hat rpm (this is the last known working version), go to
> Paul> runlevel 5 to provide indirect XDMCP and then upgrade to gdm
> Paul> 2.0beta4 when gdm is running.
> 
> Which means you'll keep running beta2...
> 
> And since beta2 works while beta4 dumps core, it seems the Helix
> people applied a patch they shouldn't have.  Jacob?
> 
> (The difference between beta2 and beta4 is a pile of patches from Red
> Hat.  No change in functionality, and it most certainly works
> providing XDMCP service).