Besides the FAQ pointers listed below, there are some excellent resources to help you:
There are several possibilities of loging in on the actual running client environment to perform necessary checks. Depending on the problem you're having, not all will be available.
If you can already login on the server from your thin client, you can use ltsp-localapps to start a local xterm.
localapp not working
Things to check when troubleshooting a broken ltsp-localapp problem:
1. Make sure LOCAL_APPS=true in your /opt/ltsp/<arch>/etc/lts.conf
2. Make sure that the shell your user is setup for is also in the client image otherwise ltsp-localapp will not work
3. Test with an new user
4. Test on a different thin client
5. Try 'su <your user>' through a root login on your thin client. You can do this a few ways first you need to make sure you have a password setup for the root user in your chroot environment and that you have updated your image. Change to VT1 (alt+ctrl+F1), login as root, type in 'su <your user>' if you cannot connect it should print out some issue. If you can then try starting xterm in here and see if it appears in VT7.
Setting a screen will allow you to log in to different systems using different tools. By default you log on with LDM on console 7, but you also define a shell login option on another console. Edit your lts.conf, reboot, wait till your LDM login screen shows up, and switch to the set console.
To enable an ssh login, chroot into your client environment and set ssh to start up when the client boots. Make sure to start it once when chrooted to create the keys. When you boot your client, you'll be able to login. Remember that for each new client build, your client keys will have changed and if you don't remove the old key from your known_hosts file, you get a "man in the middle" warning when you try to login.
Syslog is your friend, messages will be logged to /var/log/messages on the client by default. You can also setup the client logger to send logs to the server. You'll have to specifically add a SYSLOG_HOST to your lts.conf and configure your server syslogger to accept remote logfiles.
The following lines can be added the configuration of syslog-ng to accept remote logfiles. The client syslogs are logged remotely on the server at /var/log/remote/<host>.
Top like statistics of X11 client's server side resource usage:
Some interesting log files on the client:
It's a common situation that thin client have a very old-fashioned graphics card or simply graphic cards with a lack of appropriate drivers. It should be noted that to solve many of these situations, you can simply try to disable video acceleration using properly the X_OPTION_01 property:
If after that it works, apply this rule only on the problematic client. You can do that using the methods explained in the configuration page.
Get lots of pulseaudio feedback:
To check if the client's pulseaudio port is listening:
If all switches and nics on all the computers are gigabit then read no further. Just use cat 6 cabling at all points.
If all switches being used have only 10/100 bit ports then the link with the greatest need for maximum bandwidth, the one going from the server to the switch whose subnet contains the ltsp clients, is severely limited and will almost certainly result in poor performance with more than one thin client. Consider it a necessity that this link (at least) be gigabit on both ends. Therefore the server using only one nic should be checked and, if necessary, a gigabit nic card be added. Also, the switch serving the subnet containing the clients will likewise need to be replaced.
Switches exist that have only one or two gigabit ports (and the rest 10/100 bit) and these will serve as long as cat 6 cabling is used at this port and any other parts leading to the gigabit nic on the server. In the case where the server is using two nics, one for the local subnet containing the clients and the other for the subnet containg the link to the internet, only the former need be gigabit as the internet links are usually much slower anyway than 100 mps.
The need to assess the bandwidth is even greater in the context of ltsp. The graphical application Epoptes is already available in many distro repositories and has many features especially designed to enhace the ltsp experience. Below is a link that explains how this tool can also be used to measure bandwidth. It is an essential read. http://www.epoptes.org/documentation/lan-benchmark
If the switch is "managed" (also called "smart") and thus is configurable through its own webserver like interface, check the above test with 802.3x flow control enabled and disabled to determine if one setting gives better results. If, however, the switch is "unmanaged" then there is still the possibility of changing settings on the gigabit network interface controller (nic) on the server. Note that some chipset manufacturers allow a tool such as ethtool to access and change these settings. If the chipset of the onboard nic on the server is unresponsive to changing its settings, an alternative would be to add a gigabit nic card whose chipset would.
The link below gives further information on this topic and can apply to many distros.
Assuming that eth0 is the gigabit nic the ethtool commands appropriate for this discussion are:
ethtool --show-pause eth0 (shows autoneg and rx and tx settings)
ethtool --pause eth0 autoneg off rx off (turns off the flow control settings that are relevant)
ethtool --pause eth0 autoneg on rx on (turns on the flow control settings that are relevant)
These commands must be issued by root but will be reset after rebooting. Add the desired command to a line just before the line containing exit 0 in /etc/rc.local if the setting is to be valid after a reboot.