If you run FileNet P8 or CM8 tools on AIX or Linux via X11 forwarding, you have probably seen this: the GUI half renders, freezes or disappears entirely, and the console shows a cryptic message like this one:
Xlib: sequence lost (0x1001d > 0x832d) in reply type 0x0!
In this post I explain what is behind it and how to get the problem under control in practice.
What does the message mean?
Every request an X11 client sends to the X server carries a sequential number. „sequence lost“ means the client has lost track of these numbers and can no longer match replies to their requests. Typical causes are:
- multiple threads accessing the same X connection without synchronization (a classic with Java and SWT applications),
- SSH X11 forwarding getting out of step, especially in „untrusted“ mode,
- an outdated local X server (Xming, Exceed, old VcXsrv or MobaXterm versions).
Where does this show up in ECM environments?
Virtually every graphical Java or Eclipse tool running remotely on the server is affected, for example:
- the FileNet Configuration Manager (Eclipse/SWT based),
- InstallAnywhere installers in Swing mode (
-i swing), - the CM8 System Administration Client,
- any other Java GUI you „just quickly“ launch over SSH.
The fixes – ordered by likelihood of success
1. Use trusted X11 forwarding
In untrusted mode (-X) the X Security Extension restricts the client, which frequently causes trouble with Java applications. Use this instead:
ssh -Y user@host
In MobaXterm, go to Settings → X11 and set „X11 remote access“ to full.
2. Disable Java2D acceleration
For Swing and AWT applications, disabling the hardware rendering pipelines often helps. Every JVM in the session picks up this variable:
export _JAVA_OPTIONS="-Dsun.java2d.xrender=false -Dsun.java2d.pmoffscreen=false -Dsun.java2d.opengl=false"
3. Eclipse/SWT: disable GTK3 and Cairo
For the Configuration Manager and other Eclipse-based tools, you can force SWT to use GTK2:
export SWT_GTK3=0
Alternatively, add the following to configmgr.ini below -vmargs:
-Dorg.eclipse.swt.internal.gtk.cairoGraphics=false
4. libxcb locking workaround for older systems
On older systems with libxcb, this switch helps against locking issues between Xlib and XCB:
export LIBXCB_ALLOW_SLOPPY_LOCK=1
5. Update your local X server
Old Xming and Exceed installations are notorious culprits. Updating to a current version of MobaXterm or VcXsrv fixes the problem surprisingly often without any further changes.
6. Bypass X11 forwarding altogether
The most robust solution is to avoid X11 forwarding entirely:
- VNC: With a VNC server (e.g.
Xvnc) on the host, the GUI runs locally on the server and only the image is transmitted. - Command line: The FileNet Configuration Manager comes with
configmgr_cl, a full-featured command-line variant. In my experience it is the more stable route on AIX anyway, and it is easy to script and document. - Silent install: Installers can run completely without a GUI using response files.
Conclusion
„Xlib: sequence lost“ is not a FileNet or CM8 bug but a symptom of the shaky combination of Java GUI, X11 forwarding and local X server. In most cases ssh -Y and an up-to-date X server are all you need. If you regularly configure AIX systems, VNC or the command line will make your life much easier in the long run.
Have you come across other workarounds or special setups? Let me know in the comments.