[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

problem with nxserver and debian/sarge/stable

I have an amd64 system (dual AMD Opteron(tm) Processor 250) with the
offically unreleased debian/sarge/stable system of which I am very happy
and proud to be using.  Indeed, the problem I am about to describe is
one of the very few problems I have, and in the bigger scheme of things
quite small.  Nevertheless, it is important to solve this problem if I
am to use this machine the way I want to be using it.

I have also recently (within the last year) discovered the nomachine
suite of server/client software.  I started using this when they offered
it for free; provided the number of clients remains at or below 2.  This
is very usable for me.  These packages, which have been made available
for debian machines, are extremely useful and, in my opinion, the best
for remote access to the machine.  This machine is a rack-mounted
machine (pampered in an air-conditioned "clean" room) that only gets
accessed at the front console on rare occasions.

This debian/amd64/sarge/stable system has been set up to run 32-bit
applications where necessary as per the instructions on the debian site
for both local 64-bit entrant (using configured 32-bit libraries) and
the chroot environment.  32-bit applications such as firefox work great
in this manner.  Indeed, the 32-bit nxclient application also works
great except for one flaw I am about to describe.

The 32-bit nx packages are installed by forcing dpkg to ignore
architecture dependence.  They also require 32-bit libstdc
++2.10-glibc2.2 libraries that are also configured into the system so
that nxserver runs and nxclient can access the machine as expected.  No
problem here.

The problem:

On the remote machine, running the amd64 nxserver via the nxclient 

Whenever any attempt is made to get out of the active nxclient window
(such as minimize, or change windows, or virtual screens), the client
machine completely disconnects from the X server and stops all processes
that are running within the X server on the client machine.  The remote
process can be resumed since it appears to the nxserver that the process
has been suspended (not terminated), so it is not fatal, but VERY
inconvenient.  This does not happen on any of the 32-bit (non-amd64)
nxservers I have; only this amd64 server.

The actual error message that gets printed to the Xorg.0.log file at the
time of the X disconnect is

(EE) Error loading keymap /var/lib/xkb/server-0.xkm

0: /usr/X11R6/bin/X(xf86SigHandler+0x81) [0x80c3971]
1: [0xb7f40420]
2: /usr/X11R6/bin/X [0x815a32d]
3: /usr/X11R6/bin/X [0x8156a1f]
4: /usr/X11R6/bin/X(CompositeGlyphs+0x9a) [0x814409a]
5: /usr/X11R6/bin/X [0x814bbbc]
6: /usr/X11R6/bin/X [0x81470b5]
7: /usr/X11R6/bin/X(Dispatch+0x18f) [0x808693f]
8: /usr/X11R6/bin/X(main+0x485) [0x806e715]
9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7d308cc]
10: /usr/X11R6/bin/X(FontFileCompleteXLFD+0xa1) [0x806da51]

Fatal server error:
Caught signal 11.  Server aborting

I would very-much like to fix this problem.  Could anyone help on this
or seen this before ?  The remote machines running nxclient are also
Debian/Stable/Sarge machines, and in one case, a Ubuntu/Edgy machine.

James D. Freels, Ph.D.
Oak Ridge National Laboratory

Reply to: