On Thu, 2005-01-20 at 17:27, Kyrre Ness Sjobak wrote: > tor, 20.01.2005 kl. 12.20 skrev Jonathan Andrews: > > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > > Hi, > > > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > > Is XDMCP, remote X bust in core 3 ? > > > > > > I was using it not so long ago and it was working fine. > > > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > > jonspc:1" in the log ? > > > > > > I'm suprised that's the only message you get - a glance at the code > > > suggests if you're getting this error message (which is from the master) > > > you should be getting another message from the slave. > > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > > I think email is on a go-slow, please look back if you have time. > > > > Some comments on this and a few other things > > > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > > is started it seems to undergo a name change to "gdm-binary" without > > being owned by gdm or anything called gdm. As a result its not possible > > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > > something here or this a bit naff ? > > > > it is. But you have the tools gdm-restart etc. (just type gdm*tabtab* > and you'l find 'em Thanks, i've found it - yet another small shell script. In a way you are making my point nicely. Gnome broke the way xdm works when they ported it into gnome, then they keep bodging on another shell script for the functionality thats missing. I know in the global scheme of things its a minor point, but breaking the sensible way process control works just to add a few lines of logic before and after the process seems to be a bit ... well ... you get the idea ! I have to admit gdm is pretty though (after xdm anything looks better) :-) - but to many bodges ... *** warning - nasty idea for Unix purists *** Linux is general seems a bit confused about process control, init, xinetd and rc all overlap slightly in functionality. Couldn't the entire machine come up with just a slightly better xinetd and config files ? xinetd treats socket connects as an event - but isn't starting, stopping or changing runlevel just another event ? Jon
