Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

Troubleshooting X

News	Recommended Links	Architecture	X display manager	XDMCP	Troubleshooting X	"Can't open display" Error
Configuration	Fonts in X	Exporting_display	Xdefaults	Using xauth
vnc	Cygwin/X	X11 security	Tips	History	Humor	Etc

The transport mechanism between an X client and X server allows X clients to execute on remote hosts or on the same machine as the X server. The transport method is implicitly defined by the value of the DISPLAY environment variable or the X client code specifying the parameter directly to the OpenDisplay routine.

The way X communicated is defined by the value of $DISPLAY variable. The values can have three forms:

Shared Memory Transport (SMT) This is the fastest transport method and only available for clients running on the same host as the X server process. To set the DISPLAY variable, omit the host name portion, for example: # export DISPLAY=:0
UNIX sockets This is only applicable to for clients running on the same host as the X server process. To set the DISPLAY variable, use the following syntax: # export DISPLAY=unix:0
Internet sockets. To display X clients on the first display on the TCP/IP host mercury, set DISPLAY as follows (we assume the use of the Korn shell):

export DISPLAY=mercury:0

The current setting of the variable can be found with the command: # echo $DISPLAY

Before resetting the variable, write down the current setting.

Verifying that there is not configuration errors in xorg.conf

The xorg.conf might have a wrong value/entry. You can try the following procedures

init 3

cd /etc/X11

mv xorg.conf xorg.conf.old

cp xorg.conf.install xorg.conf

init 5

retest

in case previous method didn't help, try the following

init 3

sax2 -r

check keyboard, mouse and resolution configuration. Save the file, issue init 5 and retest it

I've seen cases where switching the runlevels didn't validate the new configuration so, you might need to reboot the server to validate the changes on steps 1 and 2 in case you don't see any difference.

Testing client/server connectivity

Test the validity of your DISPLAY variable by executing a simple well-known client.

For example, if your application does not seem to connect to your X server, execute:

# xsetroot -solid white

# xsetroot -solid red

Does your X server screen change color?

If it does not, check each the following typical errors:

Ensure that you are viewing the correct screen
DISPLAY not set or malformed Run: # echo $DISPLAY ted2

# xsetroot -solid white 1356-265 xsetroot: Unable to open display: ted2. In this example, the DISPLAY variable is not set correctly.

It is missing :0 at the end.

Invalid DISPLAY host name

Run: # echo $DISPLAY bogus:0 # xsetroot -solid white 1356-265 xsetroot: Unable to open display: bogus:0. # ping bogus 0821-062 ping: host name bogus NOT FOUND In this example, the TCP/IP host name component of the DISPLAY variable refers to a host that does not exist.

Client hangs

Run: # xsetroot -solid white

xsetroot: Unable to open display: rally:0.

In this example, there is a long pause or hang after running the xsetroot command. Attempt to ping the host and check if the X server is running on that host. Perhaps your client does not have a route to the X server.

Connection refused Run:

# xsetroot -solid white

Xlib: connection to "mossad:0.0" refused by server Xlib:

Client is not authorized to connect to Server

xsetroot: Unable to open display: mossad:0.

The X server maintains an access control list, allowing certain hosts to be denied access. For a machine running an X server on AIX, the default access control list disables all other hosts. To enable all hosts to connect, use the xhost command. For example, run the following command on the same host as the X server is running:

# xhost + The syntax to allow host specific access is as follow: # xhost + The xhost command is part of the X11.apps.config fileset, which, depending on the level of AIX you are running, may not be installed by default.

Missing output

Run: # xsetroot -solid white

If the command executes without error and without delay, yet the result is not visible, ensure you are viewing the correct screen. If you are using multiple graphics adapters in your machine and/or multiple X servers, you may be looking at the wrong screen. 8.4.4 Failed X client start Now that you have verified the functionality of the X server, run your application in place of the well-known X client above.

If this fails to start, check the following symptoms: X protocol error messages Run: # ./my_app X Error of failed request: BadWindow (invalid Window parameter)

Major opcode of failed request:

1 (X_CreateWindow) Resource ID in failed request: 0x200003e8 Serial number of failed request: 3 Current serial number in output stream: 5 This indicates a run-time error received by the client application. For example, an inappropriate operation is performed on the X resource or a requested resource is not available.

The above example shows the output from the default X error handler. A user application may call a custom error handler by using the function XSetErrorHandler(). Function isolation is aided by the client application calling XSynchronize() to enable the X server’s synchronization of an X protocol request and the X server’s completion of the request. This ensures that the application will terminate at the point of the X call causing the problem, rather that after the event due to the X servers buffering of requests.

exec format errors

Run: # ./my_app exec(): 0509-036 Cannot load program ./my_app because of the following errors: 0509-022 Cannot load library libXm.a[shr4.o]. 0509-026 System error: A file or directory in the path name does not exist. or # ./my_app exec(): 0509-036 Cannot load program ./my_app because of the following errors: 0509-023 Symbol _XmStrings in ksh is not defined. 0509-023 Symbol XmStringLtoRCreate in ksh is not defined. 0509-026 System error: Cannot run a file that does not have a valid form These examples indicate an installation problem; either the libraries referenced by the executable at load time are missing or the version of the libraries is downlevel. In the first case, the libXm.a library is missing. It must be installed for the application to run.

In the second case, symbols cannot be located in the libraries found on the machine. Check with the supplier of the client software to find out what libraries the symbols are expected to be in and what version should be installed. Generally, specific knowledge of the location of the symbols within libraries is required.

X kernel extension

The functionality of the X server is extended with the addition of X extensions.

The method to load an X extension will depend on the method used to start the X server. /usr/lpp/X11/defaults/xserverrc controls the loading of X extensions and other customizations. Refer to AIX 5L Differences Guide, SG24-5765, for every new X extension that is included in the new release. For CDE, also refer to Section 8.6.2, “Login screen does not appear” on page 281. 8.5.2 Installing verification commands The commands xrdb -symbols and xdpyinfo enable you to check for loaded X extensions. The xrdb command is part of the X11.apps.rte fileset. The xdpyinfo command is part of the X11.samples.apps.clients fileset.

Checking X extensions

With xrdb, check for the -DEXT_ entries. For example: # xrdb -symbols -DHOST=ted2 -DSERVERHOST=ted2 -DSRVR_ted2 -DDISPLAY_NUM=0 -DCLIENTHOST=bob3 -DCLNT_bob3 -DVERSION=11 -DREVISION=0 -DVENDOR="International Business Machines" -DVNDR_International_Business_Machines -DRELEASE=5 -DNUM_SCREENS=1 -DEXT_SCREEN_SAVER -DEXT_SHAPE -DEXT_XTestExtension1 -DEXT_xColormapExtension -DEXT_aixCursorExtension -DEXT_XAixExtension -DEXT_xDirectAccessExtension -DEXT_XInputExtension -DSCREEN_NUM=0 -DWIDTH=1280 -DHEIGHT=1024 -DX_RESOLUTION=3596 -DY_RESOLUTION=3606 -DPLANES=8 -DBITS_PER_RGB=8 -DCLASS=PseudoColor -DCLASS_PseudoColor=33 -DCOLOR -DCLASS_PseudoColor_8=33 -DCLASS_DirectColor_8=34 If you are using xdpyinfo, check the loaded extensions list. For example: # xdpyinfo | pg

number of extensions: 8 XInputExtension xDirectAccessExtension XAixExtension aixCursorExtension xColormapExtension XTestExtension1 SHAPE SCREEN-SAVER . Some APIs may require that extensions to the X server are loaded before running an application. Check your API below and verify that the extension is loaded: OpenGL – abx (xAncillaryBufferExtension) – mbx (Multi-Buffering) – GLX (GLX) graPHIGS – xgpshm (GP-MIT-SHM) PEX – mbx (Multi-Buffering) – pex (X3D-PEX) 8.6 CDE problem determination CDE is the default graphic interface on AIX 5L. 8.6.1 CDE log files If you run into a problem with CDE, the first place you should look is the log files: /var/dt/Xerrors $HOME/.dt/startlog $HOME/.dt/errorlog /tmp/xlogfile

/var/dt/Xerrors contains errors that occur when the Login Server is started. The location of this log file can be changed using the Dtlogin.errorLogFile resource in /usr/dt/config/Xconfig. Session Manager logs problems with session startup in the $HOME/.dt/startlog file. Various desktop applications log errors to $HOME/.dt/errorlog. For example, errors that occur when an action is loaded will be logged in $HOME/.dt/errorlog. X logs errors to /tmp/xlogfile. It is important that you look at these log files to diagnose problems. We list common problems you may meet and their solutions. 8.6.2 Login screen does not appear This can happen when customizations to the X servers file were made, but the command does not execute properly. Check the log files and confirm that X or xinit will start. If X or xinit will not start, go to Section 8.3.1, “Start X server” on page 270. Next, look for /etc/dt/config/Xservers and see if it was customized. If it was, verify that the command will execute from an low function terminal (LFT). If not, look for customizations made directly to /usr/dt/config/Xservers. Customizations of the /usr/dt files are discouraged because they may be overwritten at the next upgrade of CDE. The default /usr/dt/config/Xservers file contains the following line: :0 Local local@console /usr/lpp/X11/defaults/xserverrc -T -force :0 To start the X server, the Login Manager then executes: /usr/lpp/X11/defaults/xserverrc -T -force :0 The xserverrc executable is a shell script, so customizations to the start of X could be made directly to the xserverrc file. If no changes to either of the Xservers files are detected, then check to make sure the /usr/lpp/X11/defaults/xserverrc file is executable by all users.

File mode 755 is recommended.

Problem with login

The first step here is to check the log files for information. If you cannot get enough information from log files, you may try to run Login Manager in debug mode. If the problem is on the console, start dtlogin remotely, for example:

/usr/dt/bin/dtlogin -debug 10 | tee /tmp/

If you have to run dtlogin in debug mode, you must first stop all current dtlogin processes. Be sure all CDE users are logged out before killing the dtlogin process, or you may cause your users to lose data. If X terminates, then you must kill dtlogin, then issue the following command to restart the desktop: dtlogin -daemon; exit 8.6.4

CDE hangs

Network interface parameters (such as the host name and IP address) of a machine should never be changed while CDE is running. Always exit from the desktop and stop desktop processes to modify network interfaces. If CDE is not halted before something like the host name is changed, exit from CDE and see if you can run smit mktcpip to stop and restart the network connection. If this still fails, reboot the machine.

The DT messaging system could not be started

You may get this message in a dialog box when attempting to login to CDE: The DT messaging system could not be started. Login using failsafe, check hostname at these locations: /etc/src.sh /etc/hosts /usr/adm/inetd.sec AIX only uses the /etc/hosts file, but this message is generic for all of the CDE platforms, so do not be surprised to see files mentioned that do not exist. The message may indicate: Host name changed while still running CDE. Multiple machines on the network have the same host name.

X11 and graphics

Set /etc/hosts to recognize both the short name and the fully qualified name of your machine: 9.3.187.211 itsosrv1.austin.ibm.com itsosrv1

Make sure hostname both show the same fully qualified name for your machine. If you update /etc/hosts, check your host name. If the problem still occurs, modify /etc/hosts by adding your host name as an alias to the loopback interface line and commenting out the original name to address mapping, as below: 127.0.0.1 loopback localhost itsosrv1 # loopback (lo0) #9.3.187.211 itsosrv1.austin.ibm.com itsosrv1

Client libraries

X releases contain two numbers: The version number indicating major protocol or standards revisions and a release number indicating minor changes.

X11R6 X11 Release 6, also known as X11R6.

Major revisions of X are incompatible, but there is backward compatibility with minor releases within major revision categories.

X11R6 enhancements

Compared to X11R5, X11R6 has a lot of enhancements.

Old News ;-)

CDE Configuration

Please note that the below assumes that the user is using csh, which is far and away the most common shell in our environment.

If CDE fails, the user should attempt to log in under command line mode. That way, the user can make the appropriate edits to his/her environment to correct whatever configuration issues are present. (If the user is unable to log in under command line mode, something more serious is wrong with his/her account.) Command line mode is accessible under the "options" button of the dtlogin screen.

The quickest way to get someone to a useable CDE configuration is via the following steps in the user's home directory:

mv .dtprofile .dtprofile.old mv .dt .dt.old /usr/princeton/bin/updatedots

The above steps will replace the user's environment with the default environment upon the next dtlogin attempt. This means that any customizations that have been added to the user's environment will be lost. This option is the best one for new or inexperienced users.

CDE failures are most often a problem with the LD_LIBRARY_PATH. There are some incompatibilities between the X libraries in /usr/princeton/lib and those in /usr/openwin/lib and /usr/dt/lib. The system-specific libraries should come first in the LD_LIBRARY_PATH. For example:

setenv LD_LIBRARY_PATH /usr/openwin/lib:/usr/dt/lib:${LD_LIBRARY_PATH}
If this is the problem, the above line (or a logical equivalent) should be added in the user's .login file.
Another problem exists in older versions of the Princeton default .login file. If dtlogin attempts to source this file, and one of the msgs commands is enabled without any checking, the dtlogin session will freeze or crash. The msgs commands can be bracketed with an "if" statement, as is done in the current default .login file:

if ( ! ${?DT} ) then msgs -p endif

Alternatively, the user's .dtprofile can be instructed to ignore the .login file by commenting out the following line:

DTSOURCEPROFILE=true
The complete CDE manuals for Solaris can be found at doc.sun.com