Copyright 2002 by James McQuillan
Released under the terms of
the Gnu Free Documentation License
Last updated: Thursday, Sept. 12, 2002
A frequently heard problem when setting up an LTSP workstation is getting a gray screen, with the large X cursor. This indicates that the Xserver running on the workstation was not able to connect with the display manager running on the LTSP server.
A display manager is a program that runs on a server, and accepts
connections from workstations. The workstation tries to connect
to the display manager, to get a login dialog box. This is sort
of the graphical equivalent of running getty
on a
serial port, where getty will detect a connection from a dumb terminal
terminal and offer the Login prompt.
Examples of display managers include XDM, GDM and KDM. XDM is the old standard display manager that is included with the Xwindows distribution. GDM is the Gnome Display Manager, and KDM is the KDE Display Manager.
The GDM and KDM display managers offer great features, such as auto-login, session type menus, user icons and more.
There are several reasons why a the Xserver may not get a connection with the display manager.
In troubleshooting the Gray Screen problem, the trick is figuring which of the above conditions are causing the problem.
When I troubleshoot problems, I like to divide the problem in half, until I narrow the problem down so small that it is clear what is wrong. So, when troubleshooting a display manager problem, the simplest place to start is to see if the display manager is listening. Try this on the server:
netstat -anp | grep ":177 "
What does the above command mean ? Well, the netstat command can be used
to monitor any network connections currently active on the server, and also
show any ports that are currently being listened to, for incoming connection
requests.
The '-a' option tells netstat to show information about ALL network sockets. The '-n' option tells netstat to NOT convert IP addresses and PORT numbers to names. This can speed up the operation, especially if you have DNS problems. The '-p' option tells netstat to display the Process ID (PID) and the name of the process that is currently listening on that port. If you get an error from netstat about the '-p' option, you can skip that option. Older versions of netstat don't have the ability to tell which program is listening on a port.
We then pipe the output of netstat through the grep utility. This is so we can show ONLY the lines that contain ":177 ". 177 is the registered UDP port number that a display manager is supposed to use. Notice the blank space after the 177. This will prevent it from showing other sockets that start with 177, such as '17739'. The above command should either produce no output at all, or a line, similar to this:
udp 0 0 0.0.0.0:177 0.0.0.0:* 1407/kdm
If you don't see any output from the netstat command, and you are sure
that you typed the command correctly, then the display manager is either not
running, or not configured to accept connections from remote workstations.
Go to the next step, to see whether the display manager is running.
An added advantage to trying this test first is that if the display manager is running, and is listening on port 177, you can see all of that in one command, and you can see which display manager is running, because the '-p' option well show that.
If the previous step shows that a display manager is listening on port 177, then you can skip this step.
One problem with trying to figure out if a display manager is actually running
is the fact that there are 3 different display managers that could be running.
The good news is that they all share the last 2 characters in their name 'dm'.
The bad news is that other programs that may be running on your server can also
contain the 'dm' characters. For example, 'sendmail
'.
If you use an appropriate pattern to the grep
command, you should
be able to see just the processes you want. The following command should show
you whether xdm, gdm or kdm are running:
ps -e | grep " .dm"
Notice that it is a single space, followed by a dot (period) and the letters
'dm'.
You should see some output, similar to the following:
30289 ? 00:00:00 kdm
That shows that kdm
is running.
If you don't see any output from the above command, and you are sure that you typed the command correctly, then the display manager is NOT running. Go down to the next section
If the display manager has been confirmed to be running, and listening on udp port 177, then the next place to look is to see if the workstation is actually trying to contact the correct server.
The default network address for the server is 192.168.0.254. It is common for a sysadmin to setup the LTSP server on a different IP address, sometimes in an entirely different class-c. An often overlooked source of trouble is the entries in the lts.conf file that control which server the workstation will attempt to contact.
The LTSP workstations can be configured to request a connection from
any server on the network. This is controlled by a couple of entries
in the /opt/ltsp/i386/etc/lts.conf
file.
The following entries are looked for, in the following order:
It is possible that you've configured the display manager to run and accept remote connections, and you've configured the workstation to contact the correct server, and still, your workstation can't get a log in screen. The reason could be that you have some filtering on your network that is blocking the XDMCP packets from getting from the workstation to the server.
iptables and ipchains do basically the same thing. It is possible that one or the other is configured on your system, but definately not both.
iptables -L
If your system is not configured to use ipchains, then you will likely
see some really scary looking errors, like the following:
/lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
/lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
iptables v1.2.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
This is Ok! - If you see that error, don't worry, it simply means that your server is
NOT running iptables, and therefore, iptables is not the cause of your
display manager troubles.
If your system is configured to use iptables, then you need to look at the rules that are set. If you see output like this:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
This is Ok! - Output showing 'policy ACCEPT' for all chains indicates that all packets
are being allowed through the network, and in this case, iptables is not
the reason for the problems with the display manager.
If you do show other rules, then possibly the rules are blocking udp port 177. See the next session on Fixing the problem, to see how to turn off iptables.
ipchains -L
If your system is not configured to use ipchains, then you will likely
get the following message:
ipchains: Incompatible with this kernel
This is Ok! - If you do see that message, then it is NOT ipchains that is causing your display
manager problem.
If your system is configured to use ipchains, then you need to look at the rules that are set. The above command will display currently active rules. If they are like the following:
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
This is Ok! - It just shows that ipchains is allowing all packets, and again, ipchains is NOT the cause of
your display manager problems.
If you do show other rules, then possibly the rules are blocking udp port 177. See the next session on Fixing the problem, to see how to turn off ipchains.
If you have determined from the troubleshooting steps above, that the display manager is running, but not accepting requests from remote workstations (ie: not listening on port 177), then you need to figure out how to convice the display manager to accept remote connections.
Of course, it matters a great deal which display manager is configured to run. That should
have been discovered in step 2 of the troubleshooting section above, using the
ps -e | grep " .dm"
/etc/X11/xdm
directory.
The following files need to be setup correctly:
DisplayManager.requestPort: 0
This is the line that controls whether XDM will listen on udp port 177.
As it is configured by Redhat, it is set to '0', which tells xdm to NOT
listen on any ports, and only allow connections from the Xserver running
on the console (via UNIX Sockets).
To fix this, you can either comment out the entry, by placing a '#' or '!' in front of the line, or by changing the value from 0 to 177.
* #any host can get a login window
Note that the asterisk MUST be the first character on the line. No leading spaces
or tabs are allowed.
locate
command, or the find
command.
Once you find the gdm.conf file, open it with your favorite editor, and look for the '[xdmcp]' section. It should look like this:
[xdmcp]
Enable=true
Make sure that the 'Enable' parameter is set to 'true'. Note that older versions
of gdm used 0 and 1, rather than false and true.
Once you've found the file, open it with your favorite editor, and look for the '[Xdmcp]' section. It should look like this:
[Xdmcp]
Enable=true
make sure that the 'Enable' parameter is set to 'true'. Older versions of KDM
actually used the xdm-config file from the XDM display manager, so if you don't
find the '[Xdmcp]' section, you may need to edit the /etc/X11/xdm/xdm-config file
as described above in the XDM section.
The biggest problem with getting a display manager running is figuring out which display manager is supposed to be running. Each of the Linux distros seem to make the process very obscure, depending on which packages have been installed on the system.
You can see what runlevel the system is currently in by running
the runlevel
command. It should
return output something like this:
N 5
It is the 2nd field that indicates the current runlevel. Make sure
that it is 5. The default runlevel is set by the
initdefault
entry in the /etc/inittab file.
During the installation of LTSP, the initdefault entry should have been
set to '5'. If your initdefault entry is indeed set to '5', but your
server is still in runlevel 3, then perhaps you haven't rebooted the
server since installing LTSP. You could reboot the server, or you could
just run the init
command. For example,
you could run this:
/sbin/init 5
That will put the system into runlevel 5. Be prepared though! If
your display manager is configured to start X windows on the console,
then you may see X pop up on the screen when you least expect it.
Now, the gory details about how Redhat determines which display manager to run:
Redhat starts the display manager from the /etc/inittab file. That is,
near the end of the inittab file, there is an entry for runlevel 5 that
will run a shell script called /etc/X11/prefdm
. The
entry in /etc/inittab looks like this:
x:5:respawn:/etc/X11/prefdm -nodaemon
The secret to knowing which display manager is going to run, is to
know what the prefdm script does.
It starts by reading the /etc/sysconfig/desktop file. Within that file are lines that set the DESKTOP environment variable. If DESKTOP has a value of 'GNOME', then gdm will be the preferred display manager. If DESKTOP has a value of 'KDE', 'KDE1' or 'KDE2', then kdm will be the preferred display manager. If DESKTOP is set to 'AnotherLevel', then xdm will be the preferred display manager. If DESKTOP is not set, or is set to something else not mentioned above, then a search will be made, looking for gdm, kdm and finally xdm. Whichever is found first will be the preferred display manager.
So, once the preferred display manager is decided on, the script will check to see if the preferred display manager exists, and can be executed. If the preferred cannot be run, then it forgets about the preferred display manager and just tried gdm, kdm and finally xdm (in that order). The first display manager found will be the one.
The real downside of Redhats prefdm script is you can't simply force a specific display manager to run, regardless of the window manager or desktop environment that is desired.
On a Redhat based system, you can turn off iptables by running the following command:
service iptables stop
If you are using ipchains, the command is:
service ipchains stop
The above commands will turn off iptables/ipchains temporarily,
this should give you a chance to try the workstation again.
On a Redhat based system, you can turn it off permanently using
the ntsysv
utility, or the
chkconfig
command.
For systems such as Debian, SuSE and the others, I need more information about how to disable iptables/ipchains.